| | 16 | |
| | 17 | The following sections are intended to record notes, ideas and perhaps some discussion for the BGL. |
| | 18 | |
| | 19 | == Property Maps == |
| | 20 | One of the first things on my (Andrew Sutton) list is revisiting the property map library. It's an incredibly powerful little library that, despite its ubiquity in Boost.Graph, doesn't seem to get the respect it deserves. Anything that can completely abstract the ability to read and write data is just cool. Fortunately, I don't actually have to change anything except a little cosmetic restructuring like giving it its own directory. I'm also looking to add a new type of property map (const_property_map) that simply returns the same value. Also part of this effort is completely rewriting the docs (ugh). |
| | 21 | |
| | 22 | We also need to be clear on the best ways to use the library. Despite the fact that its so useful, almost all of its uses in Boost.Graph tend to be custom property maps that simply wrap the original ones. This is mostly done because we have to provide a graph object for a lot of function calls in the library. This seems to actually be a useful pattern, wrapping or re-defining simple or basic property maps for a specific application. |
| | 23 | |
| | 24 | == Named Parameters == |
| | 25 | During my (Andrew Sutton) work on the BGL this summer, I actually experimented with the new parameter library for a couple of the graph measures that I had implemented - and actually ran into a couple of issues. There are actually two "modes" for using named parameters. The first mode uses named parameters to overload default arguments to a function. In other words, the Boost.Parameter function simply delegates to a single dispatch function passing either user-supplied or the default values. The second mode is using the named parameter to select which function is actually called based on which arguments are actually supplied. The second mode is actually problematic because it becomes nearly impossible to document in any consistent fashion. |
| | 26 | |
| | 27 | My feeling is that some of the older interfaces use the old named parameter code to do similar things - function selection based on how the function is called. I have a gut feeling that most of the algorithms in the BGL can actually be written without named parameters at all. It may be that we have to change some of the algorithm names a little bit, but I really don't have any problems with that. |
| | 28 | |
| | 29 | In my experience there are basically three reasons that an algorithm has named parameters: |
| | 30 | * To supply pre-allocated storage of exterior properties - This can act as an optimization or as a means of getting extra information out of an algorithm. |
| | 31 | * To provide default values - Sometimes there are just a lot of parameters to an algorithm and all of them have defaults. |
| | 32 | * To emulate other types of graphs - For example, some graphs are naturally unweighted, but some algorithms require a weight map. If you want to use the algorithm, you need to provide edge weights (see Floyd-Warshall). This also happens for every graph that needs to, but doesn't, provide built-in vertex indices (e.g., adjacency lists with non-vector vertex storage). |
| | 33 | * To select different computations - All shortest path algoriths, for example, take a predecessor map and a distance map that enable (marginally) different behaviors if supplied. These could be provided as parameters to a visitor instead. |
| | 34 | |
| | 35 | My suggestion is to look very carefully at every algorithm that uses named parameters and try to determine why and if they can be written without them. My feeling is that one function should do one thing. It's a lot easier to document that way too. |
