On Tuesday, July 15, 2003, at 07:31 AM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:Sorry, Here is an example that shows the problem in a simple case:
#include <boost/graph/adjacency_list.hpp> #include <iostream>
int main()
{
boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,
boost::no_property, boost::no_property, boost::no_property,
boost::vecS> g;
std::cout << boost::source(*(boost::edges(g).first+4),g) << std::endl;
return 0;
}
The problem is adding an integer to an edge iterator of this graph. Is this a problem of the iterator adaptor library or of the BGL?
It's a BGL problem, specifically in the way it used to label its iterators and the way I translated them. These iterators were always given the "multi_pass_input_iterator" tag, because they didn't dereference lvalues yet copies could be guaranteed to traverse the same elements. The old iterator adaptors were more permissive in allowing you to take advantage of operations which weren't accounted for by the iterator category, when defined (because we didn't have a good way of expressing the iterator's real category anyway), and I guess the BGL took advantage of that. I believe that the BGL's iterators should really have a traversal category equal to that of the iterators they're adapting. It's sort-of too bad we don't have a way to express that.
Hmm, we could say that when you pass a tag which is just a traversal category tag or just an access category tag as iterator_adaptor's Category parameter, it takes the other part of the category from the Base iterator.
Thoughts?
Who's going to fix up the graph library?
A quick fix to get my codes to compile again (but which does not solve the problem) is to just remove the BOOST_STATIC_ASSERT in line 276 of iterator_adaptor.hpp.
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
