Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-04-16 15:29:38

At 12:12 PM 4/16/2001, Jeremy Siek wrote:

>I've been looking into using the named parameters technique
>for the algorithm interfaces in the Boost Graph Library.
>For example, calling Dijkstra's algorithm would look like
>dijkstra_shortest_paths(g, s, distance_map(d).predecessor_map(p));
>There are several advantages to this:
> - defaults no longer order-dependent
> - better readability
> - better defaults for "utility" properties. E.g., for color map
> the algorithm can by default use an internally allocated array.
>Ideally, we'd keep the old interface (and call it deprecated) and add
>functions for the new named parameter interface. However, there are a few
>places where the new functions would interfere with the old in terms of
>function overloading.
>So there's two options:
>1) Ditch the old interface, replace it with the new.
>2) Keep the old interface, use different names for the new functions.

3) Deprecate the old interface, put the new interface in namespace

>I'm in favor of option 1), but if there are strong feelings for
>option 2) I can be swayed.


* If you do change the interface, consider putting it in boost::graph.

* It seems like a lot of change if the advantage is only a minor interface
improvement. Only do it if you think it a really major improvement.

* What impact would it have on the book? You will be confusing people for
years (and having to answer their questions) if the book ships describing
an interface considerably different from the code.


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