From: Josh <axl...@gm...> - 2009-10-24 21:12:05
|
Problems with held references and pointers is exactly why we don't need a DeleteSelf. Auto pointers handle all the memory allocations for assets. Why would we EVER need type information in a destructor for said type? This seems live very bad design. I would rather have DeleteSelf over this. Nodes are a little different. They need to be deleted after they are removed from the scene graph. Nodes are NEVER instanced, each node is unique. Charles Lohr wrote: > The only way we can get type information in the destructor is to keep > that char * around, since the virtual char * GetType() doesn't work > right in the destructor or constructor. If we had a DeleteSelf > function, there would be no need to have that extra char *. > > Additionally, I feel it would be useful in many cases to be able to have > something say "Remove me at your earliest convenience." After all, in > the middle of an update cycle, if you remove yourself, you could have > all sorts of problems because of references to you from things like the > alpha pass. > > Charles > > > Josh wrote: > >> I don't like this. We did this deletion thing in HG1 and it was a disaster. >> >> There is an Init somewhere, either in MercuryNode or MercuryAsset. >> It is currently unused with the intention of reusing asset/nodes. >> >> I do not want a delete self. Having that in HG1 caused all kinds of >> circular deletions, it was very messy. >> >> Also, why are you storing char * of the type? We are using RTTI so we >> don't have to do this, and it increases the size a fairly large amount. >> >> >> >> >> Charles Lohr wrote: >> >> >>> It turns out that C++ does not permit virtual function calls in >>> Constructors or Destructors. >>> >>> I've added code to make a virtual call intentionally after the creation >>> of objects that so I can set a new variable "const char * Type" that way >>> I can get the type in the destructor. >>> >>> I am curious if we were planning on adding Init() and DeleteSelf() or >>> something along those lines? >>> >>> Charles >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> Hgengine-devs mailing list >>> Hge...@li... >>> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >>> >>> >>> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Hgengine-devs mailing list >> Hge...@li... >> https://lists.sourceforge.net/lists/listinfo/hgengine-devs >> >> > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Hgengine-devs mailing list > Hge...@li... > https://lists.sourceforge.net/lists/listinfo/hgengine-devs > |