Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-03-27 13:53:24

On Tue, 27 Mar 2001 kevin_vanhorn_at_[hidden] wrote:

[ points 1. to 5. about docs]

Thanks for the good suggestions! They'll go straight onto my to-do list.

kevin_> 6. Although it's simple enough to write (once you figure out how
kevin_> everything works in the library), it would be nice to have a
kevin_> uniform-cost (all edge weights 1) shortest-paths algorithm provided by
kevin_> the library. This can run in O(V + E) time, avoiding a factor of
kevin_> log(V) required by Dijkstra's general algorithm.

Isn't uniform-cost with edge weights=1 also called breadth-first search?
Perhaps this should be explicitly mentioned in the docs for uniform-cost.

kevin_> 7. It would be nice to have convenience functions for some of the
kevin_> algorithms that require you to pass in a color map. The convenience
kevin_> functions would use a color map local to the function. The color map
kevin_> is really an internal implementation detail, and it would be
kevin_> preferable if users didn't have to concern themselves with it. (Yes,
kevin_> I understand that sometimes you want to avoid repeatedly allocating
kevin_> and deallocating the color map when algorithms are called repeatedly.)

Yesterday Dave Abrahams suggested that we used a named-argument technique
for specifying parameters to the algorithms. I think this will solve
the problem... (the local color map will be the default for the color

kevin_> 8. Creating a property map from a random-access iterator (or
kevin_> random-access container) is horrendously painful. How about adding
kevin_> some convenience functions similar to the following:

Great! I'll add these in... though I may lengthen some of the


 Jeremy Siek www:
 Ph.D. Candidate email: jsiek_at_[hidden]
 Univ. of Notre Dame work phone: (219) 631-3906

Boost list run by bdawes at, gregod at, cpdaniel at, john at