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

[Frank V. C. <fr...@co...>]

Having had reason to dig into the SOMELib and boost code, the behavior
of a shared_ptr is such that when the reference count drops to zero (0),
there is no longer any need to keep the instance of the underlying
object.

Persistent backed smart pointers are an aspect of a application swap
mechanism, and has the requirement of at least two things in general:

1. A SmartPointer that can drop and re-load on demand by inheriting
(conceptually) some aspects of the shared_ptr (when drop to 0, get rid
of the object instance) but retain some unique thing needed and load the
object again.

2. Obviously a persistence framework :)

This is one of the frameworks that we will be providing at some point.

John Palmieri wrote:
> 
> 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
> 
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package