Creating objects on the stack, ObjC++ style.

CPPHack.mm

@interface GLObject : NSObject
{
    int _a;
}

- (void)logA;

@end

struct GLObject_cpp {
    Class isa;
    int _a;
    
    GLObject_cpp()
    : _a(30),
    isa([GLObject class])
    {}
    
public:
    void giveMeaning() { this->_a = 42; }
};

int main(int argc, const char * argv[])
{

    @autoreleasepool {
        struct GLObject_cpp cppObj = GLObject_cpp();
        id obj = (__bridge id)(&cppObj);
        NSLog(@"obj: %@", obj);
        cppObj.giveMeaning();
        [obj logA];
    }
    return 0;
}

@implementation GLObject

- (NSString *)description { return [NSString stringWithFormat: @"GLObject <%p>: %d", self, _a]; }
- (void)logA { NSLog(@"In %p, _a = %d", self, _a); }

@end

This is not a good idea. The 64-bit runtime (and the iOS runtime) make instance variables non-fragile; for simple examples like this one, where the base class is NSObject, it's unlikely to be a problem, but if you choose some other base class you might find that your code breaks on a newer version of Mac OS X or iOS because someone added instance variables to your superclass. (Even on the old 32-bit runtime, you should probably use @defs(GLObject), rather than repeating the member variables.)

Also, you have no guarantee that other code won't -retain your stack-based object and expect it to still exist outside of its scope on the stack.

If you absolutely must have lexically scoped objects, you're much better off using a smart pointer IMHO.

One other fun thing I just thought of; the Objective-C runtime supports C++ member variables (i.e. it will call their destructors). If you were to use an object containing a C++ member variable in code similar to that above, and something somewhere inside the @autoreleasepool does [[obj retain] autorelease], the member variables’ destructors could be called twice!

One (last) observation: -dealloc won't be called. This is good in that it means NSObject's -dealloc implementation won't try to release the memory (which would probably cause a crash), but bad in that it means that some classes wouldn’t clear up properly after themselves.