Re: [Somelib] Errors with downcasting using SOME::Object

[John P. <jo...@ma...>]

Ok, now that i have that solved how do I create an object that does not get destroyed
after the SOME::Object goes out of scope?  I don't want to keep track of more than one
pointer per object loaded.  Is there a way of telling the SOME::Object not to delete
pointers after it has gone out of scope (persistance)?

-Quinticent

Thomas Matelich wrote:

> I'll start with a list of statements:
> 1) SOME::Object<T> hasA T*, but is overloaded to act likeA :) T*.
> 2) To get the T* out of a SOME::Object, call the get() function.
>     Watch out that your SOME::Object doesn't delete the memory when you don't expect
> it.
> 3) If you want implicit conversion, define BOOST_SMART_PTR_CONVERSION.
>     This is dangerous because you might delete the pointer or have the memory go away
> as in get()
> 4) If BOOST_NO_MEMBER_TEMPLATES is not defined (and shouldn't need to be for g++),
> SOME::Object<Base> should be able to be created from SOME::Object<Derived>.
>
> > > SOME::Object<mriIVisualAsset>oAsset(assets[0]);
> > > //construct our asset
> > > if(!oAsset.construct()){ ...
> > >     asset = static_cast<mriIAsset *>(oAsset);  //error here.  I'm guessting
> > >                                                                         //the
> > template is not truly inheriting
> > >
> > >     chest->addAsset( chestpos, asset );//I should be able to mix and match
> > >                                                             // different assests in
> > my chest
>
> Since I do love the shared_ptr so much I have propagated it through all my code.  So I
> don't have these problems.  I was bit by the problem in number 2) above in a program
> I'm using this with so that is why I have gone that route.  It seems like the problem
> here is that shared_ptr documentation is not included with the program.  I would be
> tempted to just suck the shared_ptr code into the SOME::Object, but I think having
> things separate is good.  On the other hand, I had to modify the shared_ptr code from
> boost standard to make it inheritable.  So the pros of inheritance is a smaller
> interface for SOME::Object, and the cons are disjoint concepts and problems with trying
> to use Object without understanding shared_ptr, also the fact that I had to change the
> boost implementation.  What do you think?
>
> So anyway the solution to your problem is one of the following:
> 1) define BOOST_SMART_PTR_CONVERSION
> 2) asset = static_cast<mriIAsset*>(oAsset.get());
> 3) use Object everywhere in place of pointers
> 4) use shared_ptr everywhere in place of pointers
>
> A couple of other notes.  I usually just use the lowest (furthest to the base) possible
> level in my inheritance hierarchy as the template parameter for the Object.  That way,
> I don't have to worry about downcasting.  Also, shouldn't static_cast be dynamic_cast?
>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel