Re: [Boost-users] Graph Library - bundled properties, internal & external properties

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-03-14 10:41:33

On Mar 11, 2005, at 6:28 PM, Elvanör wrote:
>>> My last problem is with the depth_first_search() algorithm... and of 
>>> course bundled properties. This algorithm takes a const Graph &; but 
>>> I want to be able to modify (while running the algorithm) the 
>>> bundled properties!! That is the whole point of running this 
>>> algorithm. I don't want to change the structure of the graph (the 
>>> abstract graph - links from vertices to edges, etc), while running 
>>> the algorithm, of course, but I do want to change when I want my 
>>> bundled properties... that is not possible (at least, not without 
>>> compiler warnings, which I don't like :-) due to the fact that 
>>> depth_first_search expects a const graph.
>>
>> Yeah, this is an annoying problem. We'd like to be able to take 
>> either a const or a non-const graph, but doing so would require two 
>> overloads of the algorithm, which we really can't do (too much 
>> code!).
>
> Like someone else pointed out, what do you mean by too much code? It 
> would require too much time? Or would it be considered a problem for 
> more "fundamental" reasons (ie, that could lead to trouble in existing 
> code, etc...)?

Oops, the reply I'd sent never made it out of the outbox. It should 
show up before this message...

>>  I suggest that you put a non-const reference to the graph from 
>> within your visitor and use that instead of the graph that is passed 
>> to the event functions.
>
> I am not sure I understand how you would do that... Am I correct in 
> understanding that you would declare a non const reference as a member 
> in your visitor?

Yes.

>  And then you would have to pass the Graph object  when you create the 
> visitor. That means a visitor would be suitable for only one graph 
> (that is not a problem in my case, just a remark) on which you intend 
> to use the visitor on.

Yes, unfortunately.

> Another way would be to use pointers to objects as bundled properties, 
> instead of directly the object themselves. I think that should work 
> and that's what I am using right now.
>
> Basically it only changes that in your visitor, it's not 
> g[v].some_member = 4; but g[v]->some_member = 4; (if g is the graph).
>
> Seems to work fine.

Sure, that'll work. I would typically try to avoid doing that, if only 
because I wouldn't want to have to deal with allocating/deallocating 
the pointers.

One other alternative would be to const_cast the graph that the visitor 
gets. It's ugly, but it will work.

        Doug