|
Boost : |
From: Jeremy Siek (jsiek_at_[hidden])
Date: 2004-04-05 14:43:28
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_at_[hidden]>
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)
_______________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk