[boost] Re: [BGL] MutablePropertyGraph questions

From: Chris Russell (cdr_at_[hidden])
Date: 2003-02-02 17:37:24

Hi Emily, I just read your paper and think it's excellent. A while ago (some
months past), I think I hacked together a solution to a similar problem and
made a mental note to post it into the Wiki for analysis by folks who really
know what they're doing at some point in the future. You post (sorry I was
not previously following this thread) brings this back to my attention.

I'm not sure I completely understand your approach (my ignorance). Would you
please clarify these points for me:

Your heterogeneous list mechanism employs custom containers that look like
STL containers? Or can you actually use STL containers? Algorithms must be
written custom and your paper explains how. Is this correct? Or am I missing
something?

I very much like the high-level concept of heterogeneous collections of
objects. It's extremely useful (I'll give some examples in a moment).

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.

What I use this for (question: can I use your approach to achieve these ends
better?):

In your paper "section 7: Where varlist can be useful" you discuss using
your technique to work with heterogeneous collections of classes containing
different settings. I use my CMoniker hack similarly. I pass around
references to my some_stl_container<CMoniker> and let the called method
determine which elements in the container they "know" how to deal with -
effectively I enumerate the CMoniker's and dispatch on type.

Another place where I use CMoniker (and this is directly related to the
mutable property graph I think), is in BGL property maps. This effectively
lets me associate any CMonikerBase-derived class with an edge or vertex
using an unmodified version of Mr. Siek's property map. What's it good for?
File this under "this is cool": I use BGL directed graphs, specifically
forests, to abstract expressions. Vertices are operands, edges are
operators. I use a topological sort and a variant of Alexandrescu's double
dispatch idea to evaluate the entire graph as an expression generically.
Specifically I use this approach to deserialize XML streams but I think it's
generally useful.

So do you think I can use your varlist idea instead of my CMoniker? That
would be excellent as I don't really like CMoniker but haven't had time to
fix it. If so, I'm interested in trashing my CMoniker and working your stuff
into the mix instead.

- Regards

cdr

"Emily Winch" <boost_at_[hidden]> wrote in message
news:1044203223.2147.34.camel_at_jenny.my.router...
> On Wed, 2003-01-29 at 15:30, Jeremy Siek wrote:
> > On Wed, 29 Jan 2003, Vladimir Prus wrote:
> > ghost> I think the best approach would be to make this concept explicit,
and
> > ghost> independent from BGL. Something like
> > ghost>
> > ghost>    type_indexed_container<
> > ghost>      mpl::list<
> > ghost> pair<vertex_name_t, int >,
> > ghost> pair<vertex_distance_t, int> > > c;
> > ghost>    c[vertex_name_t()] = 10;
> > ghost> I wonder if something like this already exists... I vaguely
recall
> > ghost> someone was doing that.
> >
> > Yes, Emily Winch was working on this, and I thought she was going to
> > submit to boost. The following URL has a paper she wrote about this.
> >
> > http://www.oonumerics.org/tmpw01/schedule.html
>
> I would be very happy to submit it to boost, and several people have
> suggested this. I think it would be a mistake to submit it for a formal
> review without any prior discussion.
>
> I have mentioned this a couple of times now, and the lack of feedback
> led me to think that nobody was particularly interested in it. That's
> easy to believe, since when I wrote the paper it was really more from a
> "hey, this is cool" perspective than "hey, this would be really useful".
>
> However, people keep asking about it, or suggesting similar ideas, which
> suggests that there is some interest.
>
> So, I have a question: Why no feedback?
>
> a) The library is not something that people think makes sense in Boost.
> b) The library uses the wrong approach to the problem and someone should
> submit something else.
> c) The library is not something that anyone would really use. (Hey,
> Jeremy. I'm sure you said you would use it).
> d) People think it's a great idea but just never got round to having a
> look or making any comments.
>
> Emily
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>