views:

134

answers:

4

Hi, I am mostly a C++ developer, recently I am writing iPhone applications.

The memory management on iPhone is OK to me, due to resource limitation, it's encouraged to use reference counters rather than deep copy.

One annoying thing is I have to manage the reference counters by myself: alloc means counter = 1; retain means counter++, release means counter--

I wish to write a shared_ptr like class for Cocoa Touch, so I rarely have to manually manipulate the reference counters by myself.

I doubt if there's any existing code for that, and I'd like to hear some advices, today is the 5th day since I started to learn objective c

Thanks.

A: 

Resource management in Cocoa can be tricky: some API calls automatically retain a reference and some don't, some return an autoreleased object, some a retained object. By shielding this in a shared_ptr class, you'll more likely to make mistakes. My advice is to first take the "normal" Cocoa route until you're fairly experienced.

Frederik Slijkerman
+1  A: 

You forgot case 4

[4] you need to pass a pointer to an object out of a method as the return value.

This is where you need -autorelease.

I suggest you read the memory management rules and write some real code before you attempt this little project so that you can get a feel of how memory management is supposed to work.

JeremyP
I think I got your point:If the function only returns member pointer, it would be OK, coz someone will take care of it:- (UIButton*) getButton(){ return m_button_ptr;}But if it returns a local allocated variable, it should be added to the pool, and the pool will terminate it finally:-(UIButton*) getButton(){ UIButton* btn = [[UIButton alloc] init]; [btn autorelease]; return btn;}Thanks!! :D
shader
A: 

Have you looked into [object autorelease]? Perhaps that would make things a bit easier.

JBRWilkinson
+1  A: 

As long as you learn the memory management rules first, there is no real problem with shared_ptr - it can help you in C++ contexts but doesn't let the ownership questions magically disappear.
shared_ptr supports a custom deallocator so the following:

@interface A : NSObject
- (void)f;
@end

@implementation A
- (void)dealloc { NSLog(@"bye"); [super dealloc]; }
- (void)f { NSLog(@"moo"); }
@end

void my_dealloc(id p) {
    [p release];
}

// ...
{
    shared_ptr<A> p([[A alloc] init], my_dealloc);
    [p.get() f];
}

... outputs:

moo
bye

... as expected.

If you want you can hide the deallocator from the user using a helper function, e.g.:

template<class T> shared_ptr<T> make_objc_ptr(T* t) {
    return shared_ptr<T>(t, my_dealloc);
}

shared_ptr<A> p = make_objc_ptr<A>([[A alloc] init]);
Georg Fritzsche
Georg, thanks for the help!!! That's a great answer. One minor thing, if I use shared_ptr<NSObject> as a member in a Cocoa class[some Controller or UIView], I cannot take advantage of the property and synthesized feature of obj c... I don't know what will happen if I comebine the two together...
shader
Georg Fritzsche
As an after-thought a shared pointer for wrapping ObjC instances is actually overkill as they are already reference-counted - an `intrusive_ptr` that doesn't do a seperate ref-count would be better. But that has one or two other intricacies that i'll have to look into on the weekend or next week.
Georg Fritzsche