Hello, first I do not if this is the right list. I new to the boost mailling lists. I found a bug in the edge_range function of adjancency list. I condensed a short example. When compiled with MSVC 9 and Debug settings I get a debug assertion, "sequence not ordered". From my understanding the edge_range function needs the stored edge list to be sorted for the std::equal_range function. If I inspect "c" with the debugger the edges are not sorted but in the same order as they were added to the graph. Arne P.S.: If this not the right place for reporting bugs can you point to the right bug tracker/etc?
On Fri, 16 Jul 2010, Arne Schwabe wrote:
Hello,
first I do not if this is the right list. I new to the boost mailling lists.
I think boost-users is typically where bug reports go, but I think this list is fine as well. The bug tracker (Trac server) is at <URL:https://svn.boost.org/>, but people also report many bugs only on the lists.
I found a bug in the edge_range function of adjancency list.
I condensed a short example. When compiled with MSVC 9 and Debug settings I get a debug assertion, "sequence not ordered".
From my understanding the edge_range function needs the stored edge list to be sorted for the std::equal_range function. If I inspect "c" with the debugger the edges are not sorted but in the same order as they were added to the graph.
You are right. The edge_range() function should not be provided for out edge containers that are not associative containers. I disabled it in r64074 on the Boost trunk; see if that changes how your code behaves.
P.S.: If this not the right place for reporting bugs can you point to the right bug tracker/etc?
See above, but don't worry about it for this issue. -- Jeremiah Willcock
You are right. The edge_range() function should not be provided for out edge containers that are not associative containers. I disabled it in r64074 on the Boost trunk; see if that changes how your code behaves.
Would it be appropriate to return a filter iterator for non-associative containers? Andrew Sutton andrew.n.sutton@gmail.com
On Fri, 16 Jul 2010, Andrew Sutton wrote:
You are right. The edge_range() function should not be provided for out edge containers that are not associative containers. I disabled it in r64074 on the Boost trunk; see if that changes how your code behaves.
Would it be appropriate to return a filter iterator for non-associative containers?
That would produce the right semantics, but I'm not sure it satisfies the performance requirements (since stepping the filter_iterator can take arbitrarily long). We can certainly do it, though. Do you think it's good to put in? -- Jeremiah Willcock
Would it be appropriate to return a filter iterator for non-associative
containers?
That would produce the right semantics, but I'm not sure it satisfies the performance requirements (since stepping the filter_iterator can take arbitrarily long). We can certainly do it, though. Do you think it's good to put in?
Not really. I'm not sure there are that many people actually using the functionality. If somebody really wants it, we could provide it. Andrew Sutton andrew.n.sutton@gmail.com
On 16.07.2010 23:26, Andrew Sutton wrote:
Would it be appropriate to return a filter iterator for non-associative
containers?
That would produce the right semantics, but I'm not sure it satisfies the performance requirements (since stepping the filter_iterator can take arbitrarily long). We can certainly do it, though. Do you think it's good to put in?
Not really. I'm not sure there are that many people actually using the functionality. If somebody really wants it, we could provide it.
I tried to use it. :) But since the count of my edges are rather small per node (something <= 10) I can iterate over the out_edges() list Arne
participants (3)
-
Andrew Sutton -
Arne Schwabe -
Jeremiah Willcock