[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSData initWithBytesNoCopy:length:deallocator:]
From: |
Niels Grewe |
Subject: |
[NSData initWithBytesNoCopy:length:deallocator:] |
Date: |
Wed, 27 Jul 2016 00:04:18 +0000 |
Hi guys,
I just implemented the -initWithBytesNoCopy:length:deallocator: initialiser for
NSData and NSMutableData (this appeared in OS X 10.9). This takes a block as
the last argument which allows you to customise how memory will be deallocated.
This is very useful when you have a memory buffer whose lifetime is tied to
some other resource that you want to discard once the NSData is no longer
needed.
Unfortunately this required adding an ivar to hold the block, so there is a
slight complication: To maintain strict binary compatibility, NSDataMalloc and
NSMutableDataMalloc instances will deallocate themselves if called with this
initialiser and return a new object of the correct subclass instead. This could
be avoided if we added the block ivar to NSDataMalloc and NSMutableDataMalloc
directly, but that’d break any consumers subclassing these classes (assuming
the fragile ABI).
Now I am of the opinion that since NSData is a class cluster, nobody should
have any business subclassing these anyways, but I wanted to solicit some input
on the issue before making this kind of change: Would it be acceptable to make
this a common ivar? Should we bump the minor version to indicate that this
might be a breaking change or do we regard the internal organisation of the
class cluster as an implementation detail that we can change on a whim?
Thanks,
Niels
signature.asc
Description: Message signed with OpenPGP using GPGMail
- [NSData initWithBytesNoCopy:length:deallocator:],
Niels Grewe <=