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