[boost] Re: Re: [BGL] MutablePropertyGraph questions

From: Chris Russell (cdr_at_[hidden])
Date: 2003-02-03 03:37:35

Indeed. boost::any does look very similar. Some differences:

- Invoking CMoniker's operator= or copy constructor doesn't duplicate the
shrouded object, it duplicates a void * and increments a refcount on the
contained CMonikerBase object the idea being that CMoniker's typically
contain heavy objects that are costly to copy. You can additionally
construct a CMoniker using another version of its constructor I didn't
discuss that does not do reference counting on the contained object (freeing
the object is somebody else's responsibility).

- CMoniker has two methods I didn't discuss: duplicate and clone. Duplicate
returns a new CMoniker containing a new CMonikerBase-derived object
initialized using its default constructor. Clone returns a new CMoniker
containing a new CMonikerBase-derived object initialized using its copy
constructor.

I'm beginning to understand Emily's suggestion better now I think. One of
the things I use the CMoniker::Clone method for is for building "factory"
maps. e.g.

typedef std::map<std::string, CMoniker> mapNameIndexedFactory_t;
typedef mapNameIndexedFactory_t::iterator mapiterNameIndexedFactory_t;
typedef std::map<typeid, CMoniker> mapTypeIndexedFactory_t;

... the idea being that I might use this for:

mapNameIndexedFactory_t mapNameIndexedFactory;
// ... populate map
mapiterNameIndexedFactory_t mapiterNameIndexedFactory =
mapNameIndexFactory.find("some name");

CMoniker newDuplicateMoniker =
(*mapiterNameIndexedFactory).second.Duplicate();
CMoniker newClonedMoniker = (*mapiterNameIndexedFactory).second.Clone();

... so I'm still trying to figure out if Emily Winch's varlist helps me do
this more elegantly that my admittedly inelegant CMoniker thing.

- Regards
cdr

"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:3E3E0ED9.40205_at_cs.msu.su...
> Chris Russell wrote:
> > Let me first describe my heterogeneous container hack and perhaps you
could
> > point why it's poor (your feel better on a quick read of your paper and
this
> > is a good way to help us all understand this a bit better).
> >
> > My goal was to be able to use standard STL containers and iterators with
> > heterogeneous collections of objects. My hack was to declare a class
> > CMoniker that takes a pointer to some CMonikerBase-derived class through
a
> > templated constructor. This constructor does two things: it casts the
> > pointer to a void * and stores it in a private member. Additionally it
uses
> > RTTI to record the type. CMonikerBase is invasive; it provides reference
> > counting for the object and operator overloads for STL containers. Any
class
> > that derives from CMonikerBase can then be stuffed into a CMoniker, and
I
> > then use the standard STL containers/iterators to work with homogenous
> > collections. A CMoniker has a templated operator: template <typename
Type>
> > operator Type&() that internally uses RTTI to test Type and throw an
> > exception if it doesn't match the internal type squirreled away in the
> > constructor. Ugly - yes. The filtering operation you propose in your
paper
> > is similar to little helper classes I write to enumerate elements in my
> > some_stl_container<CMoniker> to produce another container full of
objects of
> > a given type - again this is inelegant but it does seem to work.
>
> I'm probably wrong, but it looks like boost::any. I can't tell a
difference,
> at least.
>
> - Volodya
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>