Archived

This topic is now archived and is closed to further replies.

Self Destructing Object

This topic is 5378 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Does anybody know how to impliment self destroying objects like the DX objects calling a release function? In a singleton, you could keep track of the instance as static and could have a "destroy" method within the class. The problem with that is that it is a singleton and can''t have many instances.

Share this post


Link to post
Share on other sites
"The problem with that is that it is a singleton and can''t have many instances"

You are right that a singleton can not have multiple instances. However, a singleton may have multiple references to it.

You singleton implementation should handle this sort of thing by itself. If it doesn''t, then does it qualify as a singleton handler?

Share this post


Link to post
Share on other sites
Well, you're going to have to implement some sort of reference counting mechanism if you're not implementing the object as a COM object. There are several discussions on singleton implementations in the forums. Take a look.

Personally, I prefer global variables. For objects that MUST be active for your application to operate a global instance that is referenced through an extern Class InstanceName is appropriate and simple. If your singleton is in a DLL, why not implement it with COM using ATL which has a singleton model built into it and is easy to use?

I know that there will be many people that have alternate views on this and that is their right. I'm not going to argue semantics.

[edited by - LordShade on March 25, 2003 11:41:10 PM]

Share this post


Link to post
Share on other sites

  
struct Object {
void addRef() { ++refCount; }
void release() { if(!--refCount) delete this; }
Object() : refCount(1) {}
virtual ~Object() {}
private:
int refCount;
};



  
struct SomeObj : Object {
void sayHello() { cout<<"Hello\n"; }
};



  
int main() {
SomeObj* obj = new SomeObj;
obj->release();
return exit_success;
}


you asked how to do your own com? well, dunno.. but thats what i use quite often in some sort, rather simple, not?

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
I''m not sure I get the question ... there are many different questions in this area.

Do you want to know the syntax or legality of such things in C++?

- syntax: delete this; - legal IF no one is ever going to try to use a pointer to the object again, which basically means, as long the normal rules which would allow delete to be called are true.

Do you want to know what uses there are for such things?

- Singletons, refcounted memory management, objects whose lifetime cannot be determined easily by a client.

Do you want to know what kinds of things to watch out for when creating / using such systems?

- one, you MUST decide if the destructor should be made private or not - leaving the destructor public means a client can circumvent your self managing logic ... and there is nothing you can do about it (deleting an object twice is not valid) ... but making the destrucot private means you can never create one of these objects on the stack ...

- also, the user can do many stupid things to self managed objects, so they need to be clearly informed what operations are legal or not ... such as copying, and what operations MUST be done or accompanied by provided function calls.

Or do you want to ask about implementing a singleton "manager" object, that manages the life of multiple actual objects, guaranteeing they are deleted eventually?

- this is fairly straitforward ...

Or do you need a singleton variant?

- just because singleton is a pattern with certain rules, doesn''t mean you cannot create any type of class you want, implementing SOME singleton or singleton like features / rules, but violating others ... the singleton is a tool with multiple facets, use whichever you need ... for instance you might use an interface which looks like a singleton, to provide clients with access to a public resource, like a printer or network connection, but you could return different pointers in return, to allow automatic load distrobution accross all available resources ... (note this can only work if there is absolutely no need for the customer to use a particular resource ... or to guarantee that they always get the same one) ... there are just limitless variations of singleton-like objects. READ the definition of singleton VERY CLOSELY ... and then write the defintion of the object you desire to make VERY CLOSELY ... and implement that (not the singleton)

Share this post


Link to post
Share on other sites