in_edges for a directedS adjacency_list

Hi, Is there a reason that the in_edges are not being maintained for a directedS adjacency_list? A quick look through implementations of boost::detail::add_edge(*) indicates correct maintainance for a bidirectional case, and reuse of the out_edges for the undirected case. I'm hopefully not missing something obvious to more enlightened souls and would appreciate any ideas to get the in_edges correctly for a directedS adjacency_list. thanks, -sr

On Wed, Jul 06, 2005 at 03:05:57PM -0700, sr kumar wrote:
Hi, Is there a reason that the in_edges are not being maintained for a directedS adjacency_list?
I recently came across the following excerpt from http://www.boost.org/libs/graph/doc/using_adjacency_list.html Note especially the last sentence. Directed and Undirected Adjacency Lists --------------------------------------- The adjacency_list class can be used to represent both directed and undirected graphs, depending on the argument passed to the Directed template parameter. Selecting directedS or bidirectionalS choose a directed graph, whereas undirectedS selects the representation for an undirected graph. See Section Undirected Graphs for a description of the difference between directed and undirected graphs in BGL. The bidirectealS selector specifies that the graph will provide the in_edges() function as well as the out_edges() function. This imposes twice as much space overhead per edge, which is why in_edges() is optional.
participants (2)
-
sr kumar
-
Todd A. Gibson