Boost logo

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