Hi Doug, On Apr 5, 2004, at 1:50 PM, Douglas Paul Gregor wrote:
Another idea I had was to make vertex_descriptor some kind of pointer proxy that defined operator-> to return City*.
If you still want convertability to an (unsigned) int, you'll need to either store that in the class derived from City or store it directly, so we'll probably need a proxy in any case.
Personally, I'd be willing to pay for the few extra memory ops
I should have made my main point clearer: using a proxy with an int member would not necessarily require extra memory ops to get the index, as would using an actual pointer. Here's a sketch of the idea: template <class T> class vertex_descriptor { T* m_property; unsigned int m_index; public: vertex_descriptor(T* prop) : m_property(prop) { } T* operator->() const { return m_property; } unsigned int get_index() const { return m_index; } // or perhaps operator unsigned int() const { return m_index; } };
(who knows? they may get optimized away)
Probably not. Today's optimizing compilers very rarely touch pointers and heap operations. It's that whole aliasing problem.
in most of my work. I think having more user-friendly graph adaptors graph<Vertex, Edge> and digraph<Vertex, Edge> would help the usability of the library; adjacency_list can be for those that need maximal performance (although I suspect that they'd roll their own graph data structures/algorithms anyway).
I agree that if we can't find a way to make adjacency_list easier to use, we should provide another class type. However, it may be possible to make adjacency_list easier to use. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek@osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington Graduating in August 2004 and looking for work C++ Booster (http://www.boost.org) _______________________________________________