iOS any beneficial reason to use self->

[straber]

I was looking at the source code for a sample application I downloaded and I noticed that the author of the code always syntax like

[self->_someVariable doSomething];

to call methods on ivars instead of

[_someVariable doSomething];

Is there any reason to use self->, or is it just that person's coding style?

Thanks,

 

[Duncan C]

I was looking at the source code for a sample application I downloaded and I noticed that the author of the code always syntax like

[self->_someVariable doSomething];

to call methods on ivars instead of

[_someVariable doSomething];

Is there any reason to use self->, or is it just that person's coding style?

Thanks,

No there's not.

In fact, I would strongly suggest staying away from that syntax.

In the case of self, it ends up creating a slightly more indirect reference to the same instance variable. (along with requiring more typing and making the code harder to read.)

In the case of another object, it enables you access that other object's (public) instance variables without using properties, something I never do as a matter of policy.

 

[PhoneyDeveloper]

It's a coding style used by Quinn at Apple's DTS, who undoubtedly wrote the sample code you're looking at.

The reason for it is to emphasize the difference between local variables, parameters and ivars. If your ivars are always named with a leading underscore then using self-> is redundant.

It has no effect on efficiency.

 

[firewood]

Yes!

Is there any reason to use self->

Yes. Absolutely. Anyone who says otherwise is wrong.

You need to directly access ivars in audio callbacks, and any other hard real-time code, where the the potential latency of any Obj C messaging is far too long.

Also from any portable C code and in the performance critical inner loops of any C code, which is a proper subset of Objective C.

Objective C messaging can be slow. And slow code wastes the users battery life. It's only because most Cocoa UI delegates are called so much more slowly that beginning programmers never notice.

 

[Duncan C]

Yes. Absolutely. Anyone who says otherwise is wrong.

You need to directly access ivars in audio callbacks, and any other hard real-time code, where the the potential latency of any Obj C messaging is far too long.

Also from any portable C code and in the performance critical inner loops of any C code, which is a proper subset of Objective C.

Objective C messaging is slow. And slow code wastes the users battery life. It's only because most Cocoa UI delegates are called so much more slowly that beginning programmers never notice.

Except that the OP was asking about self->ivar. In that case, I believe it's actually slightly slower than just using ivar directly (not a property). Directly accessing an iVar is a direct memory reference, not a method call. In fact, the compiler will often optimize it into registers if it is used in a tight loop.

Your comments about the overhead of using properties is certainly correct, although that overhead is really pretty small. The modern Objective C runtime does a lookup and caching of method addresses the first time you invoke a method, and in a loop, the method call overhead is all but eliminated. (Granted it's not completely eliminated...) Your example of an audio callback is certainly a case where every clock cycle counts and this type of optimization is warranted, but most developers don't deal at that level very often if at all.

I'm an old assembler jockey, and am used to counting clock cycles and crafting code that's as fast as it can possibly be (On a 1 mHz 8-bit processor you had no choice.) However, I rarely have to worry at that level on iOS. Efficient algorithms have a much, much greater impact on the speed of your program than efficient implementations. A carefully crafted n-squared algorithm will still be unacceptably slow with a large dataset, now matter how tightly coded it is.

 

[firewood]

You can't get a ivars directly from a C subroutine. You need to pass in self as a parameter to access them.

Also, self->foo allows using an ivar that's covered by a local variable of the same name. Useful when mangling together "Portable" C code with Obj C.

 

[Duncan C]

You can't get a ivars directly from a C subroutine. You need to pass in self as a parameter to access them.

You can in c functions compiled into a .m file, and called from an instance method. That's how I usually combine C functions and Objective C code.

Also, self->foo allows using an ivar that's covered by a local variable of the same name. Useful when mangling together "Portable" C code with Obj C.

Good point about exposing instance variables hidden by local variables, although I tend to rewrite one or the other to avoid that problem 'cause the potential for future confusion is high.

Anyway, I stand by my answer to the OP, that in normal circumstances (Objective C code) there is no reason to use self->foo syntax.

 

[dejo]

[self->_someVariable doSomething];

But the OP's given example has nothing to do with C subroutines, correct?

 

[PhoneyDeveloper]

If you have an ivar _foo

_foo = x;
self->_foo = x;

will generate the same machine code.

There is no difference from the standpoint of efficiency.

self.foo is different of course.