gnustep-dev
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


reply via email to

[Prev in Thread] Current Thread [Next in Thread]