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 b
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’
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
>>
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
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 discusse
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];
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 r
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]
.. 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 h
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 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 09:29 , William Squires wrote:
> Thanks - reducing the scene to just the score label reveals that - without
> the background - the (solid) background color is now a dark gray, rather than
> black, and I can just make out the (simulated) title bar at the top where -
> on a r
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
G
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
On 2014 Apr 26, at 12:56, Eric Smith wrote:
> Can someone post a code snippet that shows how to us authorization services
> to run 'sudo chown'
This article has a little sample code near the bottom, but you should read the
whole thing.
https://developer.apple.com/library/mac/documentation/se
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
___
Hi, I'm experiencing crashes in my app on Mac OS X (fully updated
Mavericks). It is extremely hard to simulate, seems more or less random.
But it crashes inside OpenGL. I googled it, and it seems I'm not the only
one, but apparently nobody knows what it is. Any ideas?
Thread 0 Crashed:: Dispat
On Apr 27, 2014, at 4:58 PM, Vojtěch Meluzín wrote:
>
> Hi, I'm experiencing crashes in my app on Mac OS X (fully updated
> Mavericks). It is extremely hard to simulate, seems more or less random.
> But it crashes inside OpenGL. I googled it, and it seems I'm not the only
> one, but apparently no
18 matches
Mail list logo
