RE: [Boost-users] graph peculiarities

----------------------- 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

Hi Brent, It is hard to see the motivation by staring at adjacency_list. Instead, consider the graph algorithms and the idea that they should work with many different kinds of graph data structures. The design of the graph concepts (such as IncidenceGraph, etc) were motivated by this, and then adjacency_list was merely created as a class that fulfills these interfaces. There is indeed some added complexity and indirection in the BGL interfaces, a price to pay for the genericity. It's a tradeoff. On Mar 14, 2005, at 6:16 PM, Arias Brent-P96059 wrote:
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. :)
There are several kinds of edge iterators... in_edge_iterator, out_edge_iterator, edge_iterator. Which one would you use? Also, if you got rid of edge descriptors, then the property maps would have to work directly with edge iterators. Instead of working with a single edge descriptor, they would have to work with several edge iterators. Edge descriptors really are the abstract for this. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek@osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________
participants (2)
-
Arias Brent-P96059
-
Jeremy Graham Siek