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" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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 > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
