Re: KVC, binding multiple properties, top level object
Graham Cox wrote: > NSInteger is a typedef for 'long', which size depends on the platform (32/64 > bit), so valueForKey: will wrap it as a NSNumber using type 'long’. That’s not quite true. While it is the desired effect that NSInteger behave like long, NSInteger was used because the spots in the API where NSInteger is used today used to be of type ‘int’. So on 32 bit, NSInteger is int (which is 32 bits, same as long) and on 64 bit NSInteger is long (which is 64 bits). This means that old 32bit code doesn’t break that relies on these parameters being ints, like calls to NSLog (which would otherwise complain about the use of “%d” instead of “%ld”). Of course that code *will* break when compiled under 64-bit, but the compiler doesn’t know whether a particular 32-bit value should be expanded to 64 bits or not, so it breaking means you see there is an issue and can review and fix it, which you’d have to do anyway on a change between architectures like this. On 14 Jul 2014, at 03:55, Trygve Inda wrote: > So what is the purpose of the NSInteger access within NSNumber eg > integerValue and setIntegerValue ? NSNumber is used both for in-memory access to data (e.g. when you use setValue:forKey:, whether explicitly, or implicitly through bindings, or for use in userInfo dictionaries like on NSNotification and NSTimer) and for serialization of data to disk. NSInteger is a data type intended only for in-memory use. It expands certain memory-limited parameters like array indexes and other memory offsets to 64-bit when compiled and running as a 64-bit app on a 64-bit CPU, while keeping old code written against the 32-bit ABI compiling. The existence of NSInteger support in NSNumber is solely for this in-memory use. It doesn’t really make sense to persist an NSInteger to disk *unless* you never plan to support another architecture. E.g. if your app is for a festival this year and is 64-bit-only, you would be safe to persist an NSInteger to disk. But I’d still consider it bad style. You should use a type that has a known size (or rather, a known range) and stays that way when saving to disk. If you can’t load the larger values in a 32-bit app, at least by loading them as a long long, you get the whole value and can put up an error to the user and refuse to load the file that way. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: KVC, binding multiple properties, top level object
On 13 Jul 2014, at 23:29, Trygve Inda wrote: > NSNumber just seem a bit more flexible since they can be added to > dictionaries (such as in the userInfo of a Notification). NSNumber is more complicated to use (constant calls to integerValue and valueWithInteger: etc. to actually work with them) and carries a bit more overhead (it creates a new NSObject subclass on the heap every time, while an NSInteger can be created directly on the stack). In an ideal world, everything in ObjC would be a real object, but in practice, you need to optimize this aspect. A naive estimate of the size of an object consists of a length (internally kept by malloc), an isa pointer, and the actual payload (in this case one NSInteger). So you get a size of 8 + 8 + 8, which triples the amount of memory needed for each number (with tagged pointers and attached data it can go up or down, but it’s a good ballpark). Add to that the actual pointer in the object that refers to it, which is another 8 bytes. This means 3x more data flows through the CPU caches. It also destroys memory locality, because the NSNumber gets allocated somewhere in free memory, and not near the object that references it. And accessing the number incurs one polymorphic method call. Method calls are fast, but since you’re not really doing polymorphism, it’s orders of magnitude slower than just directly accessing an NSInteger and using the CPU’s built-in instructions. You’re paying for a lot that you’re never using. So in summary: - NSNumber is slower - NSNumber is larger - NSNumber requires you to write more code, which means you can make more bugs - NSNumber has lots of neat features that you’re not really using right now (the flexibility you mention above) In short, unless you’re actively using the flexibility of NSNumber right now, you do not want to use it. Given bindings are for UI updates, and the UI generally only updates in response to user interaction (and users perform an action about every few seconds, which might as well be an ice age apart as far as modern CPUs are concerned), it’s usually better to pay the overhead of creating a new NSNumber the moment you need it to wrap your number, instead of always having one even when you don’t need it. But keep in mind, premature optimization, root of all evil, yadda, yadda, yadda... Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: KVC, binding multiple properties, top level object
On Jul 14, 2014, at 3:44 AM, Uli Kusterer wrote: > NSNumber is more complicated to use (constant calls to integerValue and > valueWithInteger: etc. to actually work with them) and carries a bit more > overhead (it creates a new NSObject subclass on the heap every time “Every time" hasn’t been true for years (since 10.7?) NSNumbers representing “small enough” integers are represented as tagged pointers and don’t cause any heap allocation at all. The exact meaning of “small enough” is an implementation detail (and differs greatly between 32-bit and 64-bit) but in practice, integers up to ±1000 should be cheap, I believe. But I agree about NSNumbers being more complicated. The only time you need to use an NSNumber is if you want to stick a number into a collection or otherwise need to treat it as an object. —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: KVC, binding multiple properties, top level object
On Mon, 14 Jul 2014 09:11:58 -0700, Jens Alfke said: >But I agree about NSNumbers being more complicated. The only time you >need to use an NSNumber is if you want to stick a number into a >collection or otherwise need to treat it as an object. It's also useful for optional values, where a nil NSNumber is different from a zero valued integer. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
Okay, now if I want to insert 1024 bytes of new data at the beginning of a populated NSMutableArray, is there a better way than this: NSMutableData *bigMData = ... // (approx 1MB of data); int origlength = bigMData.length; uint8_t *newBytesPtr = ... . . . // Shift contents over by 1024 bytes [bigMData replaceBytesInRange:NSMakeRange(1024,origlength) withBytes:bigMData.bytes length:origlength]; // Add new contents to the beginning [bigMData replaceBytesInRange:NSMakeRange(0,1024); withBytes:newBytesPtr length:1024]; This seems a bit messy. -Carl On Jul 12, 2014, at 1:51 PM, Matt Gough wrote: > don’t you just want: > > [bigData replaceBytesInRange:NSMakeRange(0, 1024) withBytes:NULL length:0]; > > ?? > > I am sure NSMutableData is well optimized for shunting its contents around > internally. > > Matt > > > On 12 Jul 2014, at 20:36, Carl Hoefs wrote: > >> Basically what I would like is an NSMutableData method like this: >> >> - (void)resetDataRangeTo:(NSRange)range >> >> Parameters >> range >> The range within the contents of the receiver to be considered the new >> contents. >> >> >> But, since that doesn't exist yet, is it safe to "shift" the contents in >> place of an NSMutableData? I'm trying to avoid having to copy the contents, >> which is > 1MB. >> >> In this example, I want to remove the leading 1024 bytes in a large >> NSMutableData: >> >> NSMutableData *bigData = ... // (approx 1MB of data); >> >> UInt64 byte_shift = 1024;// skip over first 1024 bytes >> UInt64 new_length = bigMutData.length-byte_shift; >> NSRange moveRange = NSMakeRange(0,new_length); >> >> [bigMutData replaceBytesInRange:moveRange >> withBytes:bigMutData.bytes+1024 >>length:new_length]; >> [bigMutData setLength:new_length]; >> >> -Carl >> >> ___ >> >> 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/devlists.mg%40googlemail.com >> >> This email sent to devlists...@googlemail.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: [NSMutableData resetDataRangeTo:(NSRange)range];
On 14 Jul 2014, at 19:12, Carl Hoefs wrote: > Okay, now if I want to insert 1024 bytes of new data at the beginning of a > populated NSMutableArray, is there a better way than this: Yes. [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr length:1024]; > > NSMutableData *bigMData = ... // (approx 1MB of data); > int origlength = bigMData.length; > uint8_t *newBytesPtr = ... > . . . > // Shift contents over by 1024 bytes > [bigMData replaceBytesInRange:NSMakeRange(1024,origlength) > withBytes:bigMData.bytes > length:origlength]; > // Add new contents to the beginning > [bigMData replaceBytesInRange:NSMakeRange(0,1024); > withBytes:newBytesPtr > length:1024]; > This seems a bit messy. ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
On 14 Jul 2014, at 11:12 am, Carl Hoefs wrote: > Okay, now if I want to insert 1024 bytes of new data at the beginning of a > populated NSMutableArray, is there a better way than this: Sure; why not just do [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr length:1024]; ...? -ben ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
On Jul 14, 2014, at 11:22 AM, Mike Abdullah wrote: > [bigMData replaceBytesInRange:NSMakeRange(0,0) >withBytes:newBytesPtr > length:1024]; On Jul 14, 2014, at 11:23 AM, Ben Kennedy wrote: > [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr > length:1024]; Wow, that's damn clever! My thinking is so clunky. It never would have occurred to me that NSMutableData could expand (0,0) into (0,1024) out of thin air! Awesome! THX!! -Carl ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
On 14 Jul 2014, at 11:30 am, Carl Hoefs wrote: >> [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr >> length:1024]; > > Wow, that's damn clever! My thinking is so clunky. It never would have > occurred to me that NSMutableData could expand (0,0) into (0,1024) out of > thin air! Awesome! Well, it's basically the inverse of your first question, for which Matt Gough already provided the answer. NSMutableData's method is well designed and well named because it does exactly as it implies: replaces some range of data (whatever size) with another chunk of data (whatever size). -ben ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
On Jul 14, 2014, at 11:35 AM, Ben Kennedy wrote: > On 14 Jul 2014, at 11:30 am, Carl Hoefs > wrote: > >>> [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr >>> length:1024]; >> >> Wow, that's damn clever! My thinking is so clunky. It never would have >> occurred to me that NSMutableData could expand (0,0) into (0,1024) out of >> thin air! Awesome! > > Well, it's basically the inverse of your first question, for which Matt Gough > already provided the answer. > > NSMutableData's method is well designed and well named because it does > exactly as it implies: replaces some range of data (whatever size) with > another chunk of data (whatever size). > > -ben > Yes, I guess it's the semantics that threw me. I was attempting to "insertBytesInRange" not "replaceBytesInRange", so I had it in my mind that the one couldn't do the other. But that's the whole purpose of the NSRange. Very cool. -Carl ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
On Jul 14, 2014, at 11:48 AM, Carl Hoefs wrote: > Yes, I guess it's the semantics that threw me. I was attempting to > "insertBytesInRange" not "replaceBytesInRange", so I had it in my mind that > the one couldn't do the other. But that's the whole purpose of the NSRange. > Very cool. The equivalent function in the ‘classic’ Mac OS had the very appropriate name of Munger( ) since it would munge bytes around in a heap block. Knowing how to use Munger was a sign of geek cred in the old (80s-90s) Mac dev community. ( http://www.mactech.com/articles/mactech/Vol.12/12.05/Handles2/index.html ) —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: [NSMutableData resetDataRangeTo:(NSRange)range];
On Jul 14, 2014, at 11:54 AM, Jens Alfke wrote: > > On Jul 14, 2014, at 11:48 AM, Carl Hoefs > wrote: > >> Yes, I guess it's the semantics that threw me. I was attempting to >> "insertBytesInRange" not "replaceBytesInRange", so I had it in my mind that >> the one couldn't do the other. But that's the whole purpose of the NSRange. >> Very cool. > > The equivalent function in the ‘classic’ Mac OS had the very appropriate name > of Munger( ) since it would munge bytes around in a heap block. Knowing how > to use Munger was a sign of geek cred in the old (80s-90s) Mac dev community. > > ( http://www.mactech.com/articles/mactech/Vol.12/12.05/Handles2/index.html ) > > —Jens Okay, 1 last question on this. Is there a way to promote-in-place an NSData object into an NSMutableData object? -becomeMutable or some such? I'm trying to avoid copying megabytes of data/sec if it's avoidable. -Carl ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
On Jul 14, 2014, at 12:15 PM, Carl Hoefs wrote: > Okay, 1 last question on this. Is there a way to promote-in-place an NSData > object into an NSMutableData object? -becomeMutable or some such? I'm trying > to avoid copying megabytes of data/sec if it's avoidable. Nope. Part of the contract of an NSData object is that it’s immutable. If you could change it to mutable, other code that had a reference to that object could find its data changing out from underneath it, causing trouble. If you’re the one creating the NSData object in the first place, can you create it as an NSMutableData? Then you won’t have to make any copies. —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: [NSMutableData resetDataRangeTo:(NSRange)range];
The reason you can't do exactly what you're asking is because there may be other owners of the immutable object. Since NSMutableData is a subclass of NSData, you should ask yourself where you're creating the object and try creating it from the start as mutable, and also if there are owners of the object that would be okay with that difference. -- Gary L. Wade (Sent from my iPad) http://www.garywade.com/ > On Jul 14, 2014, at 12:15 PM, Carl Hoefs > wrote: > > Okay, 1 last question on this. Is there a way to promote-in-place an NSData > object into an NSMutableData object? -becomeMutable or some such? I'm trying > to avoid copying megabytes of data/sec if it's avoidable. ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
On Jul 14, 2014, at 12:57 PM, "Gary L. Wade" wrote: > where you're creating the object On Jul 14, 2014, at 12:53 PM, Jens Alfke wrote: > If you’re the one creating the NSData object in the first place, can you > create it as an NSMutableData? Certainly that makes sense enough, just hoping against hope that there might be a certain exemption to it. Unfortunately I'm "stuck in the middle" of an existing workflow. I receive an NSData from an outside section, must delete certain cruft, add other fields, and pass it on. So I have to do this: modifiableData = [ NSMutableData dataWithData: [ external call that gives me an NSData ] ]; Will get it working first, and if there's a performance panic, perhaps something can be done (but I extremely doubt it). Thanks for the info! -Carl ___ 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: [NSMutableData resetDataRangeTo:(NSRange)range];
On Jul 14, 2014, at 1:07 PM, Carl Hoefs wrote: > modifiableData = [ NSMutableData dataWithData: [ external call that gives > me an NSData ] ]; It’s shorter and more idiomatic to just say modifiableData = [external mutableCopy]; (plus an autorelease if you’re not using ARC) > Will get it working first, and if there's a performance panic, perhaps > something can be done (but I extremely doubt it). Well, the most optimal thing to do would be to create an empty NSMutableData of the correct size, then use memcpy to copy in the correct pieces from the original NSData and whatever other sources there are. That will save you some unnecessary copies and possibly realloc calls. —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: [NSMutableData resetDataRangeTo:(NSRange)range];
On 15 Jul 2014, at 4:54 am, Jens Alfke wrote: > The equivalent function in the ‘classic’ Mac OS had the very appropriate name > of Munger( ) since it would munge bytes around in a heap block. Knowing how > to use Munger was a sign of geek cred in the old (80s-90s) Mac dev community. My god, you just made me feel old. Munger() was one of my favourites :) --Graham ___ 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: Unwanted enclosingScrollView
The NSRulerViews are owned and provided by the NSScrollView. While you can certainly scroll a view without the ScrollView, you would need to reimplement a lot of its functionality yourself. These are pretty tightly coupled classes in terms of functionality. Without an NSScrollView you cannot have the NSRulerView. The Cocoa text system is elaborate and sophisticated and has a lot of dependencies to be that way. Sent from my iPhone > On 2014/07/13, at 0:08, Leonardo wrote: > > Any solution? ___ 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
