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];
>
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
___
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 cop
o 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 mu
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
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
. 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
te:
>>> 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
>>>
>>> someObje
e 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];
>>
>>
utating 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,
es. 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
ur 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];
&
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 = [someO
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 = [som
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
15 matches
Mail list logo
