Storing Objects on the Stack

Question

Is it possible to alloc space for objects on the stack? I don't want to contest the language principles, and yes, auto-release pools work very nicely. It's just a matter of curiosity (and of investigating it). I've heard of things like:

struct {
    Class isa;
} s_obj;

s_obj.isa = [NSObject class];

NSObject *obj = (NSObject *)&s_obj;

But I'm not sure if this will work properly. At least, it doesn't sound very practical since the structure of the object would need to be re-created.

Maybe overwriting +alloc, and somehow calling an alloca() behind the scenes? Looks like passing a different zone in allocWithZone: would be the best approach, but NSZone is quite undocumented. CocoaDev has an article on it, but again I'm not sure if it's the way to go. Any ideas?

Eventually, if an easy to use solution appears it would be nice to use it in addition to the already present language features.

Answer 1

Nope; can't do that. Or, technically, you can, but you cannot pass the object to any system API and you can't subclass NSObject.

The system assumes that the object is in the heap; autorelease will work as expected, and the object's lifespan can be controlled by managing a retained reference, none of which will be true for a stack allocated object.

(There is one exception; Blocks start out on the stack sometimes. Very special case and it is entirely controlled by the compiler. It also trips people up.)

---

alloca() won't work; the memory will be "allocated" (the stack pointer will be bumped) in the frame that did the allocation. As soon as you try to return the object, the allocation is gunk and the returned reference is now a dangling pointer.

NSZone is deprecated in all but declaration. OpenStep tried to perpetuate zone based allocations for the purpose of quick destruction back in 1994 or so. Proved to be way too fragile; there were way too many ways that a reference to a zone could escape into another zone and zone destruction would produce dangling pointers.

---

Capturing what was in comments on Daniel's question

• Once the stack frame containing a stack allocated object is destroyed, any references to that object are invalid. Thus, any messages to any references will have undefined behavior and will, quite likely and at best, crash outright. I.e. you can't set the retain count to some super high value because the call to release is already too late in that it will dereference through the now-invalid object reference to try and obtain the isa to try and execute the method.

• You cannot subclass NSObject in such an object because NSObject carries with it a boatload of functionality, both public like KVO, KVC, and associated objects, and various private implementation details of the system frameworks. Any of this functionality should be free to retain/release/autorelease the instance at any time because a fundamentally a retain guarantees an object's lifespan until release when subclassing NSObject.

• You can't test for "working" behavior because any assumptions related to retain/release/autorelease of the system provided frameworks are inherently implementation details that may change across any software update for any reason.