Re: About iVars declaration and property

On Thu, 17 Nov 2011 12:40:32 +1100, Graham Cox said: > >So which were you, Kon or Bal? > >(Those of use with extremely long memories might get the reference ;-) I get the reference, and I resent the implication! :) m. -- matt neuburg, phd = m...@tidbits.com, A fool +

Re: About iVars declaration and property

On 17/11/2011, at 4:31 AM, Don Quixote de la Mancha wrote: > You all speak as if you think I'm a clueless newbie, but I was a > "White Badge" Senior Engineer in Apple's Traditional OS Integration > team from 1995 through 1996. For most of that time I worked as a > "Debug Meister", in which I iso

Re: About iVars declaration and property

On Nov 16, 2011, at 11:52 AM, Don Quixote de la Mancha wrote: > On Wed, Nov 16, 2011 at 10:29 AM, Preston Sumner > wrote: >> Can you confirm that the reason the particular software you use is huge, >> bloated, and slow is specifically because of objc_msgSend() and not >> shortcomings in the a

Re: About iVars declaration and property

On Nov 16, 2011, at 9:31 AM, Don Quixote de la Mancha wrote: > According to Instruments, my iOS App now spends about half its time in > a C (not Objective-C) void function that updates the state of a > Cellular Automaton grid, and the other half in a low-level iOS Core > Graphics routine that fills

Re: About iVars declaration and property

On 11/16/11 9:31 AM, Don Quixote de la Mancha wrote: > End-user time is even more expensive than programmer time. Clearly if you are writing an operating system or other performance-critical software it's exceedingly important to optimize things are far as possible. One reason that the iPhone and

Re: About iVars declaration and property

On Nov 16, 2011, at 10:52 AM, Don Quixote de la Mancha wrote: > Did you ever use any of the early releases of Mac OS X? It was so > slow as to be largely unusable until 10.3 (Panther). I was working on OS X at that time. The main reasons for poor performance weren’t micro-level stuff like ob

Re: About iVars declaration and property

On 16 Nov 2011, at 11:31 AM, Don Quixote de la Mancha wrote: > objc_msgSend is slow as Alaskan Molasses compared to a simple C function call. Cocoa uses Objective-C for I/O and user-interaction libraries, to respond to events that take place over periods of milliseconds. For those purposes, I c

Re: About iVars declaration and property

On Nov 16, 2011, at 9:31 AM, Don Quixote de la Mancha wrote: > Despite that I implemented my own most time-critical routine in C, > objc_msgSend takes up two percent of my run time. I expect it would > be a lot more if I didn't implement that grid update routine in C. Definitely. Time-critical

Re: About iVars declaration and property

On Wed, Nov 16, 2011 at 10:29 AM, Preston Sumner wrote: > Can you confirm that the reason the particular software you use is huge, > bloated, and slow is specifically because of objc_msgSend() and not   > shortcomings in the application's design or the addition of new, > resource-intensive featu

Re: About iVars declaration and property

On Nov 16, 2011, at 10:31 AM, Don Quixote de la Mancha wrote: > I've been trying to beat these arguments into the heads of my fellow > coders since most of you lot were in diapers. Just about always the > responses are that "Premature Optimization is the Root of All Evil," > as well as that progr

Re: About iVars declaration and property

On Nov 16, 2011, at 9:31 AM, Don Quixote de la Mancha wrote: > I've been trying to beat these arguments into the heads of my fellow > coders since most of you lot were in diapers. Just about always the > responses are that "Premature Optimization is the Root of All Evil," > as well as that prog

Re: About iVars declaration and property

On Wed, Nov 16, 2011 at 8:03 AM, Kyle Sluder wrote: > On Nov 16, 2011, at 1:00 AM, Don Quixote de la Mancha > wrote: >> Calling accessors is also quite slow compared to a direct iVar access, >> because it has to go through Objective-C's message dispatch mechanism. > > objc_msgSend isn't very slo

Re: About iVars declaration and property

On Nov 16, 2011, at 1:00 AM, Don Quixote de la Mancha wrote: > Using properties significantly increased the size of my executable > file. If I had something like this: > > float a = [self foo: self.scale]; > float b = [self bar: self.scale]; > > I could cut down the size of my code quite a bi

Re: About iVars declaration and property

One other advantage to using properties over direct ivar access internally is KVO compliance. Usually I prefer to declare properties backed by ivars of a different name, then use getters/setters everywhere except inside initializers and dealloc. Frees me from having to worry about willChangeVal

Re: About iVars declaration and property

On Nov 16, 2011, at 01:00 , Don Quixote de la Mancha wrote: > Using properties significantly increased the size of my executable > file. If I had something like this: > > float a = [self foo: self.scale]; > float b = [self bar: self.scale]; > > I could cut down the size of my code quite a bit b

Re: About iVars declaration and property

Using properties significantly increased the size of my executable file. If I had something like this: float a = [self foo: self.scale]; float b = [self bar: self.scale]; I could cut down the size of my code quite a bit by caching the return value of self.scale: float theScale = self.scale; flo

Re: About iVars declaration and property

On Nov 15, 2011, at 10:54 AM, Torsten Curdt wrote: > But then again the compiler would know about these implementations. No, it wouldn’t. The compiler has no idea how NSDictionary or NSWindow are implemented. All it knows about them is what’s given in their header files. (Worse, even if it did

Re: About iVars declaration and property

On Tue, Nov 15, 2011 at 10:54 AM, Torsten Curdt wrote: >> There’s no requirement that there be such an ivar, only a method named >> -window that returns an NSWindow*. The implementation of that method is >> arbitrary. For example it might just look like >> - (NSWindow*) window { return [_parent wi

Re: About iVars declaration and property

> There’s no requirement that there be such an ivar, only a method named > -window that returns an NSWindow*. The implementation of that method is > arbitrary. For example it might just look like > - (NSWindow*) window { return [_parent window];} But then again the compiler would know about these

Re: About iVars declaration and property

On Nov 15, 2011, at 10:34 AM, Torsten Curdt wrote: > How does > > @property (nonatomic, assign) IBOutlet NSWindow *window; > > not have the information that there would need to be an ivar > > NSWindow *window; > > on 32-bit? There’s no requirement that there be such an ivar, only a method na

Re: About iVars declaration and property

On Nov 15, 2011, at 10:34 AM, Torsten Curdt wrote: >> No it can't. @property only says "I have methods named -foo and -setFoo:". >> It implies absolutely nothing about storage. > > How does > > @property (nonatomic, assign) IBOutlet NSWindow *window; > > not have the information that there wou

Re: About iVars declaration and property

On Nov 15, 2011, at 9:55 AM, Kyle Sluder wrote: >> FWIW I check on the llvm IRC channel and the response was "I wouldn't >> be surprised if there are annoying edge cases, but offhand I don't see >> any reason it couldn't be done." > > If it could've been done, they would have done it. The fragil

Re: About iVars declaration and property

> No it can't. @property only says "I have methods named -foo and -setFoo:". It > implies absolutely nothing about storage. How does @property (nonatomic, assign) IBOutlet NSWindow *window; not have the information that there would need to be an ivar NSWindow *window; on 32-bit? >> FWIW I

Re: About iVars declaration and property

On Nov 15, 2011, at 9:52 AM, Torsten Curdt wrote: >>> Think of it like the compiler generates the ivars from the property >>> definitions. So the ivar would be indeed explicit ivars - just not >>> defined as such in the classic way. >> >> Doesn't matter. The subclass still needs to know the size

Re: About iVars declaration and property

>> Think of it like the compiler generates the ivars from the property >> definitions. So the ivar would be indeed explicit ivars - just not >> defined as such in the classic way. > > Doesn't matter. The subclass still needs to know the size of its superclass > so that it generate the proper ivar

Re: About iVars declaration and property

On Nov 15, 2011, at 8:44 AM, Torsten Curdt wrote: >> In four words: Fragile Base Class Problem. >> >> The problem is that a subclass (in 32 bit OS X) needs to know the size of >> the superclass so it know how to lay out its ivars. If there is no explicit >> ivars, there is no way for the comp

Re: About iVars declaration and property

> In four words: Fragile Base Class Problem. > > The problem is that a subclass (in 32 bit OS X) needs to know the size of the > superclass so it know how to lay out its ivars.  If there is no explicit > ivars, there is no way for the compiler to know the size (since when it is > compiling the s

Re: About iVars declaration and property

On Nov 15, 2011, at 9:48 AM, Torsten Curdt wrote: >>> If you’re 64-bit only (or if you require Lion or better), there’s no real >>> reason to explicitly declare the ivars these days. >> >> As others have pointed out, this is not true. There are practical >> differences between declaring and no

Re: About iVars declaration and property

>>If you’re 64-bit only (or if you require Lion or better), there’s no real >>reason to explicitly declare the ivars these days. > > As others have pointed out, this is not true. There are practical differences > between declaring and not declaring the ivar explicitly. I almost never > declare t

Re: About iVars declaration and property

On Sun, 13 Nov 2011 01:42:07 -0600, Charles Srstka said: >On Nov 13, 2011, at 1:16 AM, ico wrote: > >> >> However, I just wonder, is it really true that there is no ANY different >> between explicitly declaring iVars and not delaring it? >> > >If you’re 64-bit only (or if you require Lion or be

Re: About iVars declaration and property

For some reason, sometimes my synthesized ivars show up in the debugger as ivars, and sometimes they don't. Can anyone explain this? I can't remember whether this is with GDB or LLDB. On 2011-11-13, at 5:24 AM, Don Quixote de la Mancha wrote: > Explicitly declaring your ivars makes them easier

Re: About iVars declaration and property

The synthesized ivars are private to the class that declares them. So you can use them as an ivar in that class's implementation, but not in a subclass implementation. Usually this is not a problem, but if you already have code that passes the ivar's address in a function call, for example, that

Re: About iVars declaration and property

I find that not having explicit instance variable declarations lets me focus the class interface. I think that focusing on the interface is more helpful in the long run. --Richard On Nov 13, 2011, at 12:16 AM, ico wrote: > If so, is it a better approach that just declare the property and let

Re: About iVars declaration and property

Explicitly declaring your ivars makes them easier to see in the debugger. Otherwise you have to call the property accessor from gdb's command line to look at it. I feel that it's helpful to declare them in any case, so I can more-easily tell how much memory each of my objects is taking up by look

Re: About iVars declaration and property

On Nov 13, 2011, at 1:16 AM, ico wrote: > I am surprise that I just know we do not need to declare instance variables > explicitly when we declare the property and use @synthesize. > > That is we do not need a instance variable to be declared that is > corresponds to the property declaration. >