|
Boost Users : |
From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-09-14 21:01:55
On Sep 14, 2005, at 7:26 PM, Jeremy Siek wrote:
> Part of the problem is the language (C++), not the library. However,
> we may be able to fix this by going to extraordinary
> lengths. Though I can't say when one of the developers will have the
> time to do this. It's quite tedious trying to imagine
> all the ways an algorithm can be misused and try to trick the
> compiler into giving a good error message.
> This is one of the reasons I wrote a Ph.D. thesis about a new
> language.
And Jeremy neglected to mention that we're trying *very* hard to get
some extensions into C++0x so that wretched error messages like these
will be a thing of the past.
>> What do to BGL experts/implementers say? Would it not be **saner**
>> to get these algorithms to work automatically no matter what graph
>> type was chosen?
>>
> The problem with std::map is that it does not provide constant time
> access to the vertex index
> (it is logarithmic). Thus, the graph algorithm will run slower; it
> won't have the advertised
> time complexity. Then we'll get bug reports from people that are
> surprised by how slow the
> algorithm is.
It's definitely slower, but I think we need to give the usability
issue more weight. I only recall ever having seen two cases where
someone complained about the BGL being to slow: one was with
betweenness_centrality, until we learned that the person had compiled
without any optimizations; the other was with bundled properties
slowing things down (due to the extra level of dispatch). On the
other hand, we get questions every week about how to create property
maps, especially edge property maps (because there's no way to avoid
managing your own edge_index_t). We should get users hooked on the
BGL first, then we can worry about getting maximal performance for
them later.
I've been thinking of a few ways to try to help users with creating
and using property maps. It's possible that "all of them" is the
right answer:
1) Make edge descriptors ordered (via <), so that users can make
associative property maps more easily
2) Create templates vertex_property_map<T, Graph> and
edge_property_map<T, Graph> that create external property maps
without much effort from the user; in particular, that'll use an
associative property map or an iterator property map depending on
whether a vertex_index property is available.
3) As Tony mentions, make the algorithms a bit more lenient
about the input graphs. They could use something like the class
templates in #2, so long as we can still get maximal efficiency out
of them when index maps are available.
4) Create new graph types (say, directed_graph<Vertex, Edge> and
undirected_graph<Vertex, Edge>) that maintain vertex and edge index
maps internally (as does the Python graph type).
Doug
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net