It would be really cool it that function supported tuples, that would make it much more readable to use more than two visitors.
It would be really cool it that function supported tuples, that would make it much more readable to use more than two visitors.
Agreed. There are a number of great cosmetic changes that Boost.Graph could use. At some point in the (hopefully near) future, I hope to be merging my SoC code. Ideally, the merge process would result in a branch of the trunk. Such a branch might also be open for a number of other improvements - like integrating other algorithms that have been in waiting in the wings. Of course, that might result in a brand new graph library (and may be subject to re-review). Andrew Sutton asutton@cs.kent.edu
On Aug 28, 2007, at 6:32 PM, Andrew Sutton wrote:
It would be really cool it that function supported tuples, that would make it much more readable to use more than two visitors.
Agreed. There are a number of great cosmetic changes that Boost.Graph could use. At some point in the (hopefully near) future, I hope to be merging my SoC code. Ideally, the merge process would result in a branch of the trunk.
Sounds good.
Such a branch might also be open for a number of other improvements - like integrating other algorithms that have been in waiting in the wings.
Are there any particular algorithms you have in mind? We've been slowly integrating contributed algorithms into the trunk. The limitation has basically been that we need to find people with time to review the algorithms, tests, documentation, etc. before merging any code.
Of course, that might result in a brand new graph library (and may be subject to re-review).
No, I doubt it. We've talked offline a few times about building "version 2" of the Boost Graph Library, which would include many cosmetic cleanups, simplified interfaces, and probably remove many of the hacks for older compilers. Such an upgrade would be mostly backward-compatible and would not need a re-review. - Doug
Such a branch might also be open for a number of other improvements - like integrating other algorithms that have been in waiting in the wings.
Are there any particular algorithms you have in mind? We've been slowly integrating contributed algorithms into the trunk. The limitation has basically been that we need to find people with time to review the algorithms, tests, documentation, etc. before merging any code.
Hmm.... I just update the trunk and realized there's already a planarity algorithm in the library - and the cycle ratio code. Oops. Maybe this would be a good opportunity to look thru the wishlist on trac and see if there are any other algorithms people are interested in.
No, I doubt it. We've talked offline a few times about building "version 2" of the Boost Graph Library, which would include many cosmetic cleanups, simplified interfaces, and probably remove many of the hacks for older compilers. Such an upgrade would be mostly backward-compatible and would not need a re-review.
I was thinking something a little more large-scale. There are some concepts in my recent work that could be back-ported (mostly to the adjacency list classes) and some new code that makes working with exterior properties a great deal easier (and cleaner). I'm also developing some ideas - I haven't put them to code - on specialized graph concepts (e.g., weighted graphs). Basically, these just simplify reasoning about the graph interface, when you need to provide property maps and when you don't. Andrew Sutton asutton@cs.kent.edu
participants (3)
-
Andrew Sutton -
Douglas Gregor -
Jens Müller