[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NSData initWithBytesNoCopy:length:deallocator:]
From: |
Niels Grewe |
Subject: |
Re: [NSData initWithBytesNoCopy:length:deallocator:] |
Date: |
Wed, 27 Jul 2016 07:21:29 +0000 |
> Am 27.07.2016 um 08:40 schrieb Richard Frith-Macdonald <address@hidden>:
>
>
>> On 27 Jul 2016, at 01:04, Niels Grewe <address@hidden> wrote:
>>
>> 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?
>
>
> The next release of base is planned to be 1.25.0 (I've already started
> updating the news/release-notes to that effect in svn) since, as announced in
> the last release, it will be removing GC support (and making other binrary
> incompatible changes).
> There are already too many changes in trunk to realistically make another
> bugfix release in the 1.29.? series from it.
> So up until we actually make the 1.25.0 release any binary incompatible
> changes are fine in trunk.
Cool. I’ve made that change in r40038.
Thanks!
Niels
signature.asc
Description: Message signed with OpenPGP using GPGMail