Re: copy and mutableCopy
Op 27 apr 2014, om 11:00 heeft Dave het volgende geschreven: > Hi All, > > A long time back, I remember reading something about the way in which copy > and mutableCopy are implemented. I think basically it said that: > > someObject = [someOtherObject copy]; > > or > > someObject = [someOtherObject mutableCopy]; > > Wouldn’t necessarily allocate any extra data storage. I’ve been searching for > it to refresh my memory, but I can’t see to find it anywhere. Does anyone > know if this document or something like it exists somewhere? > > Thanks a lot > Dave Maybe this is what you are looking for? http://disanji.net/iOS_Doc/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmImplementCopy.html Willeke ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
On Apr 27, 2014, at 10:06 AM, ChanMaxthon wrote: > I am not sure if Apple libraries COW The OP was asking about the actual behavior of the Apple libraries, not a hypothetical implementation or the implementation of a different framework. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
You know you can mmap(2) COW pages if kernel or hardware supports it right? GNUstep used COW implemented by sharing pointers (no kernel or hardware support needed) which is obvious, Apple can implement COW by using COW pages (kernel or hardware supported) COW pages cannot be told apart from copied pages but if you trap into kernel you can see the difference. Sent from my iPhone > On Apr 28, 2014, at 12:54 AM, Jens Alfke wrote: > > >> On Apr 27, 2014, at 4:06 AM, Maxthon Chan wrote: >> >> Immutables copied are just retained and returned, and mutableCopied are COW. >> Mutables copied generates COW. > > Hmm. Got any proof of the copy-on-write behavior? I’ve never heard of that > being implemented in CF/Foundation classes. > >> That would be the fastest way implementing that. > > The “would” makes it sound as though you’re just speculating. If you are, > please make that more clear. > > —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
What object are you talking about? NSData have -bytes method and others would require you drop to CF code (or probably impossible) Check for methods with "return internal pointer" attribute or fast iteration protocols. If you need fine tuned control over that you may need to drop to C or use GNUstep implementations of respective Foundation classes. (BTW GNUstep uses COW whenever possible) Sent from my iPhone > On Apr 27, 2014, at 5:00 PM, Dave wrote: > > Hi All, > > A long time back, I remember reading something about the way in which copy > and mutableCopy are implemented. I think basically it said that: > > someObject = [someOtherObject copy]; > > or > > someObject = [someOtherObject mutableCopy]; > > Wouldn’t necessarily allocate any extra data storage. I’ve been searching for > it to refresh my memory, but I can’t see to find it anywhere. Does anyone > know if this document or something like it exists somewhere? > > Thanks a lot > Dave > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com > > This email sent to xcvi...@me.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
I am not sure if Apple libraries COW but I know GNUstep uses COW on their NSData, NSDictionary and NSArray (and that and a different NSObject layout in their implementation of some classes are the reason why their libraries are faster than Apple's) Simplest way is to copy NSData sand watch for calls to memcpy(3) and values of -bytes. Sent from my iPhone > On Apr 28, 2014, at 12:54 AM, Jens Alfke wrote: > > >> On Apr 27, 2014, at 4:06 AM, Maxthon Chan wrote: >> >> Immutables copied are just retained and returned, and mutableCopied are COW. >> Mutables copied generates COW. > > Hmm. Got any proof of the copy-on-write behavior? I’ve never heard of that > being implemented in CF/Foundation classes. > >> That would be the fastest way implementing that. > > The “would” makes it sound as though you’re just speculating. If you are, > please make that more clear. > > —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
On Apr 27, 2014, at 4:06 AM, Maxthon Chan wrote: > Immutables copied are just retained and returned, and mutableCopied are COW. > Mutables copied generates COW. Hmm. Got any proof of the copy-on-write behavior? I’ve never heard of that being implemented in CF/Foundation classes. > That would be the fastest way implementing that. The “would” makes it sound as though you’re just speculating. If you are, please make that more clear. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
.. plus if anyone calls [ xxx bytes ] on any of the shared NSMutableData objects it must be copied incase the bytes are mutated and I'm sure there are a load more edge cases. You cannot say 'immutables copied are just retained and mutableCopied are COW'. There is no way to know that without having all the Cocoa source, the first is fairly likely true across most immutable objects but not guaranteed, the second is very much an optimisation/implementation detail which may or may not be applied in some, many, all, or no cases for a given class. There's a lot of classes in Cocoa, I would be fairly surprised if all of them used the exact same memory management methodology and I would not be surprised if there exists at least one class who's mutableCopy method just allocates new memory and copies the data and doesn't even think about COW at all. I would guess more than one. The good thing about copy and mutableCopy is they can be implemented any way the programmer likes as long as they return an object which is a copy or a mutable copy of the original, assuming that mutability/non-mutability even applies to that type. How they do it is entirely left to the implementer. On 27 Apr, 2014, at 10:24 pm, Britt Durbrow wrote: > Oh, and if you are implementing something like this, don’t forget to trap > writes to both the copy *and* the original object: > > myMutableClass *a=[myMutableClass makeAnObjectWithSomeBuffer:aBuffer]; > myMutableClass *b=[a mutableCopy]; > > [a mutateTheBuffer]; > > doing [a isEqual:b] should return NO; but if you didn’t trap the write to the > original object and cause the COW copies to actually do the copy then it will > erroniously return YES (and all sorts of other havoc will likely ensue…) > > > On Apr 27, 2014, at 4:06 AM, Maxthon Chan wrote: > >> Immutables copied are just retained and returned, and mutableCopied are COW. >> >> Mutables copied generates COW. >> >> That would be the fastest way implementing that. >> >> * COW = copy on write >> >> On Apr 27, 2014, at 17:06, John McCall wrote: >> >>> On Apr 27, 2014, at 2:00 AM, Dave wrote: >>>> A long time back, I remember reading something about the way in which copy >>>> and mutableCopy are implemented. I think basically it said that: >>>> >>>> someObject = [someOtherObject copy]; >>>> >>>> or >>>> >>>> someObject = [someOtherObject mutableCopy]; >>>> >>>> Wouldn’t necessarily allocate any extra data storage. I’ve been searching >>>> for it to refresh my memory, but I can’t see to find it anywhere. Does >>>> anyone know if this document or something like it exists somewhere? >>> >>> I don’t know if there’s a document, and like a lot of things with ObjC the >>> actual guarantees are pretty weak, but implementations of these methods on >>> immutable types have been turning into essentially “return [self retain];" >>> for quite some time. But that’s when the actual dynamic type is >>> guaranteed-immutable, e.g. something constructed as an NSArray, not just >>> something that’s immutable by convention, e.g. an NSMutableArray that >>> you’re passing around as an NSArray. >>> >>> John. >>> ___ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com >>> >>> This email sent to xcvi...@me.com >> >> ___ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/bdurbrow%40rattlesnakehillsoftworks.com >> >> This email sent to bdurb...@rattlesnakehillsoftworks.com > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org > > This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
Oh, and if you are implementing something like this, don’t forget to trap writes to both the copy *and* the original object: myMutableClass *a=[myMutableClass makeAnObjectWithSomeBuffer:aBuffer]; myMutableClass *b=[a mutableCopy]; [a mutateTheBuffer]; doing [a isEqual:b] should return NO; but if you didn’t trap the write to the original object and cause the COW copies to actually do the copy then it will erroniously return YES (and all sorts of other havoc will likely ensue…) On Apr 27, 2014, at 4:06 AM, Maxthon Chan wrote: > Immutables copied are just retained and returned, and mutableCopied are COW. > > Mutables copied generates COW. > > That would be the fastest way implementing that. > > * COW = copy on write > > On Apr 27, 2014, at 17:06, John McCall wrote: > >> On Apr 27, 2014, at 2:00 AM, Dave wrote: >>> A long time back, I remember reading something about the way in which copy >>> and mutableCopy are implemented. I think basically it said that: >>> >>> someObject = [someOtherObject copy]; >>> >>> or >>> >>> someObject = [someOtherObject mutableCopy]; >>> >>> Wouldn’t necessarily allocate any extra data storage. I’ve been searching >>> for it to refresh my memory, but I can’t see to find it anywhere. Does >>> anyone know if this document or something like it exists somewhere? >> >> I don’t know if there’s a document, and like a lot of things with ObjC the >> actual guarantees are pretty weak, but implementations of these methods on >> immutable types have been turning into essentially “return [self retain];" >> for quite some time. But that’s when the actual dynamic type is >> guaranteed-immutable, e.g. something constructed as an NSArray, not just >> something that’s immutable by convention, e.g. an NSMutableArray that you’re >> passing around as an NSArray. >> >> John. >> ___ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com >> >> This email sent to xcvi...@me.com > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/bdurbrow%40rattlesnakehillsoftworks.com > > This email sent to bdurb...@rattlesnakehillsoftworks.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
Immutables copied are just retained and returned, and mutableCopied are COW. Mutables copied generates COW. That would be the fastest way implementing that. * COW = copy on write On Apr 27, 2014, at 17:06, John McCall wrote: > On Apr 27, 2014, at 2:00 AM, Dave wrote: >> A long time back, I remember reading something about the way in which copy >> and mutableCopy are implemented. I think basically it said that: >> >> someObject = [someOtherObject copy]; >> >> or >> >> someObject = [someOtherObject mutableCopy]; >> >> Wouldn’t necessarily allocate any extra data storage. I’ve been searching >> for it to refresh my memory, but I can’t see to find it anywhere. Does >> anyone know if this document or something like it exists somewhere? > > I don’t know if there’s a document, and like a lot of things with ObjC the > actual guarantees are pretty weak, but implementations of these methods on > immutable types have been turning into essentially “return [self retain];" > for quite some time. But that’s when the actual dynamic type is > guaranteed-immutable, e.g. something constructed as an NSArray, not just > something that’s immutable by convention, e.g. an NSMutableArray that you’re > passing around as an NSArray. > > John. > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com > > This email sent to xcvi...@me.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
Hi,
> Apart from intellectual curiosity were you actually looking for this for a
> reason?
A bit of boh really, I’ve been profiling my App and the type of behaviour I
describe seems to be occurring. When I wrote:
myData = [self newData];
myNewData = [myData copy];
[myData release]; //If Non-ARC, removed
if ARC, I am using ARC.
I put a TO DO against it to try and check how much actual copying of data
(meaning more memory usage) was actually occurring, but it seems in most (if
not all) cases no actual data is being copied.
I was quite prepared to take the hit from the copy anyway, but it seems it
doesn't actually do any.
I realize this may change for any number of reasons, but right now, on the
config I am testing against, no data is being copied. I think it was in an
Apple Developer Videoand Keynote presentation from when the iPhone SDK was
first introduced or maybe V2 or V3 iOS SDK, but but I could be wrong.
Dave
On 27 Apr 2014, at 11:46, Roland King wrote:
> ok but you can't rely on any of this behaviour, because the only defined
> interface is copy (or copyWithZone) and mutableCopy (or rather
> mutableCopyWithZone). If NSMutableData is smart enough to do copy-on-write
> then that's great.
>
> I've certainly never seen any apple documentation which discusses the details
> of how objects do and don't copy, perhaps you were reading someone else's
> analysis.
>
> Apart from intellectual curiosity were you actually looking for this for a
> reason?
>
> On 27 Apr, 2014, at 6:32 pm, Dave wrote:
>
>> Hi,
>>
>> Yes, I can see there are no guarantees and if is *has* to copy the object it
>> will, but it has some optimisations, take this for example:
>>
>> -(NSData*) newData
>> {
>> NSData* myData;
>>
>> myData = [[NSData alloc] init];
>> //Add data to myData
>>
>> return myData;
>> }
>>
>> -(void) someMethod
>> {
>> NSData* myData;
>> NSData* myNewData;
>>
>> myData = [self newData];
>> myNewData = [myData copy];
>>
>> [myData release];
>>
>> //Do something the myNewData
>>
>> }
>>
>> I think it said, in cases like this, no real data would be copied. It also
>> said something like, the same would be true if it were using NSMutableData,
>> as long as “myData” is NOT mutated before it is released.
>>
>> It’s these types of cases I’m talking about, I realize that if objects start
>> mutating then physical copies need to be made in some cases. it’s just it
>> doesn't happen automatically just because you have invoked copy or
>> mutableCopy - physical copies only occur IF they need to.
>>
>> Thanks
>> Dave
>>
>> On 27 Apr 2014, at 10:00, Dave wrote:
>>
>>> Hi All,
>>>
>>> A long time back, I remember reading something about the way in which copy
>>> and mutableCopy are implemented. I think basically it said that:
>>>
>>> someObject = [someOtherObject copy];
>>>
>>> or
>>>
>>> someObject = [someOtherObject mutableCopy];
>>>
>>> Wouldn’t necessarily allocate any extra data storage. I’ve been searching
>>> for it to refresh my memory, but I can’t see to find it anywhere. Does
>>> anyone know if this document or something like it exists somewhere?
>>>
>>> Thanks a lot
>>> Dave
>>>
>>>
>>> ___
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com
>>>
>>> This email sent to d...@looktowindward.com
>>
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>>
>> This email sent to r...@rols.org
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
ok but you can't rely on any of this behaviour, because the only defined
interface is copy (or copyWithZone) and mutableCopy (or rather
mutableCopyWithZone). If NSMutableData is smart enough to do copy-on-write then
that's great.
I've certainly never seen any apple documentation which discusses the details
of how objects do and don't copy, perhaps you were reading someone else's
analysis.
Apart from intellectual curiosity were you actually looking for this for a
reason?
On 27 Apr, 2014, at 6:32 pm, Dave wrote:
> Hi,
>
> Yes, I can see there are no guarantees and if is *has* to copy the object it
> will, but it has some optimisations, take this for example:
>
> -(NSData*) newData
> {
> NSData* myData;
>
> myData = [[NSData alloc] init];
> //Add data to myData
>
> return myData;
> }
>
> -(void) someMethod
> {
> NSData* myData;
> NSData* myNewData;
>
> myData = [self newData];
> myNewData = [myData copy];
>
> [myData release];
>
> //Do something the myNewData
>
> }
>
> I think it said, in cases like this, no real data would be copied. It also
> said something like, the same would be true if it were using NSMutableData,
> as long as “myData” is NOT mutated before it is released.
>
> It’s these types of cases I’m talking about, I realize that if objects start
> mutating then physical copies need to be made in some cases. it’s just it
> doesn't happen automatically just because you have invoked copy or
> mutableCopy - physical copies only occur IF they need to.
>
> Thanks
> Dave
>
> On 27 Apr 2014, at 10:00, Dave wrote:
>
>> Hi All,
>>
>> A long time back, I remember reading something about the way in which copy
>> and mutableCopy are implemented. I think basically it said that:
>>
>> someObject = [someOtherObject copy];
>>
>> or
>>
>> someObject = [someOtherObject mutableCopy];
>>
>> Wouldn’t necessarily allocate any extra data storage. I’ve been searching
>> for it to refresh my memory, but I can’t see to find it anywhere. Does
>> anyone know if this document or something like it exists somewhere?
>>
>> Thanks a lot
>> Dave
>>
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com
>>
>> This email sent to d...@looktowindward.com
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>
> This email sent to r...@rols.org
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
Hi,
Yes, I can see there are no guarantees and if is *has* to copy the object it
will, but it has some optimisations, take this for example:
-(NSData*) newData
{
NSData* myData;
myData = [[NSData alloc] init];
//Add data to myData
return myData;
}
-(void) someMethod
{
NSData* myData;
NSData* myNewData;
myData = [self newData];
myNewData = [myData copy];
[myData release];
//Do something the myNewData
}
I think it said, in cases like this, no real data would be copied. It also said
something like, the same would be true if it were using NSMutableData, as long
as “myData” is NOT mutated before it is released.
It’s these types of cases I’m talking about, I realize that if objects start
mutating then physical copies need to be made in some cases. it’s just it
doesn't happen automatically just because you have invoked copy or mutableCopy
- physical copies only occur IF they need to.
Thanks
Dave
On 27 Apr 2014, at 10:00, Dave wrote:
> Hi All,
>
> A long time back, I remember reading something about the way in which copy
> and mutableCopy are implemented. I think basically it said that:
>
> someObject = [someOtherObject copy];
>
> or
>
> someObject = [someOtherObject mutableCopy];
>
> Wouldn’t necessarily allocate any extra data storage. I’ve been searching for
> it to refresh my memory, but I can’t see to find it anywhere. Does anyone
> know if this document or something like it exists somewhere?
>
> Thanks a lot
> Dave
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com
>
> This email sent to d...@looktowindward.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
On 27 Apr, 2014, at 5:06 pm, John McCall wrote: > On Apr 27, 2014, at 2:00 AM, Dave wrote: >> A long time back, I remember reading something about the way in which copy >> and mutableCopy are implemented. I think basically it said that: >> >> someObject = [someOtherObject copy]; >> >> or >> >> someObject = [someOtherObject mutableCopy]; >> >> Wouldn’t necessarily allocate any extra data storage. I’ve been searching >> for it to refresh my memory, but I can’t see to find it anywhere. Does >> anyone know if this document or something like it exists somewhere? > > I don’t know if there’s a document, and like a lot of things with ObjC the > actual guarantees are pretty weak, but implementations of these methods on > immutable types have been turning into essentially “return [self retain];" > for quite some time. But that’s when the actual dynamic type is > guaranteed-immutable, e.g. something constructed as an NSArray, not just > something that’s immutable by convention, e.g. an NSMutableArray that you’re > passing around as an NSArray. > There are indeed no guarantees. It is often the case that an immutable object 'copies' itself by just returning itself but it doesn't have to, it can make a new object if it wants. I can't think of a case where a mutable object could copy itself without allocating extra storage so in the mutableCopy case, this almost definitely isn't correct. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copy and mutableCopy
On Apr 27, 2014, at 2:00 AM, Dave wrote: > A long time back, I remember reading something about the way in which copy > and mutableCopy are implemented. I think basically it said that: > > someObject = [someOtherObject copy]; > > or > > someObject = [someOtherObject mutableCopy]; > > Wouldn’t necessarily allocate any extra data storage. I’ve been searching for > it to refresh my memory, but I can’t see to find it anywhere. Does anyone > know if this document or something like it exists somewhere? I don’t know if there’s a document, and like a lot of things with ObjC the actual guarantees are pretty weak, but implementations of these methods on immutable types have been turning into essentially “return [self retain];" for quite some time. But that’s when the actual dynamic type is guaranteed-immutable, e.g. something constructed as an NSArray, not just something that’s immutable by convention, e.g. an NSMutableArray that you’re passing around as an NSArray. John. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
copy and mutableCopy
Hi All, A long time back, I remember reading something about the way in which copy and mutableCopy are implemented. I think basically it said that: someObject = [someOtherObject copy]; or someObject = [someOtherObject mutableCopy]; Wouldn’t necessarily allocate any extra data storage. I’ve been searching for it to refresh my memory, but I can’t see to find it anywhere. Does anyone know if this document or something like it exists somewhere? Thanks a lot Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
