----------------------- The "install property" approach has some advantages when creating property maps for internal properties. For instance, you can determine if there is an "edge_weight" property and use it, without poking into the user-supplied type for the edges. ------------------------ Ok, I can see that. ---------------------------- I don't know the rationale for the original design, but I will also note that bundled properties don't (and can't) work on Visual C++ 6.0, a compiler that had to be supported when the BGL was released. ---------------------------- Do bundled properties now work with the C++ compiler of Visual Studio.NET (i.e. version 7)?

What were you expecting instead of vertex descriptors?

Keep in mind I'm a newbie to the Graph lib, but my answer is that I'd just dispense with the descriptors, and absorb the functionality straight into the iterators. So, for example, a call to source(e, g) ...would have 'e' refer to an edge iterator rather than an edge descripter. I could guess why that approach wasn't taken, but if you happen to know - please do tell. :) ------------------------------- I'm not sure the std::map<string, int> analogy holds up well, because accessing the int for a given string requires logarithmic time, which would not be acceptable for a graph. Using vertex descriptors allows the library to reference vertices without regard to their storage (or storage of their properties). ------------------------------- Ok, my bad analogy aside, isn't it also true that iterators similarly allow reference to vertices / edges without regard to their storage? Keep in mind that, as far as I can tell, you can't retrive a vertex_descripter until you've retrieved a vertex_iterator. So it appears you are dependent on iterators either way. But I suppose I don't fully appreciate the restrictions the designers faced. For example, consider the description of functor "exercise_vertex()" found here: http://boost.org/libs/graph/doc/quick_tour.html ...that makes me wonder if the descripter was simply a syntactic necessity (that an iterator could not fulfill). Thoughts? -Brent