Re: [Somelib] Perhaps a SOME::Object and SOME::SmartObject are needed

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

Make is so number one :-)

-Quinticent

Thomas Matelich wrote:

> John Palmieri wrote:
>
> > Perhaps instead of getting rid of the boost stuff which could be useful
> > to some projects we could create two seperate objects:
> >
> > SOME::Object which works like the current SOME::Object with the
> > exception that it does not destroy the pointer when it goes out of scope
> > and provides a destroy, delete, dismember, etc. method for deleting a
> > contained object.
> >
> > SOME::SmartObect which uses the boost smart pointers.
> >
> > or if you want to keep the functionality of SOME::Object the same we
> > could have a SOME::PersistantObject.
> >
> > What do you think?
>
> One of the reasons I'm leaning toward sucking some_boost::shared_ptr into
> SOME::Object is that I have changed the implementation and it would be
> confusing to someone who was using boost::shared_ptr.  I'm really thinking
> we need to eliminate some_boost.
> How about this:
> Change ClassCatalog so that instead of giving you shared_ptr's it gives raw
> pointers, and create an Object heirarchy.
>
> Object - abstract base class with virtual functions for getting the T* and
> |                overloaded operators so that it acts like a pointer.
> |
> |-SmartObject - Uses ref count
> |
> |-PersistantObject - No automatic deletion, must call destroy() or
> whatever.
> |
> |-MetaObject? Some automatic CoreLinux++ stuff (I have no idea what I'm
> talking about :)
>
> The biggest downside to this is the virtual function calls but we already
> had that, and the user can skip the Object and get the pointer directly if
> so desired.  Seems to satisfy both our requirements.
>
> --
> 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