On Mon, 22 Apr 2013, Max Moroz wrote:
Jeremiah -
Thank you - this is exactly what I was missing.
Suppose I have a class DS that I want to adapt for use with Boost.Graph in two different ways (for example, what is considered a source in one adaptation should be a target in the other adaptation, and vice versa). How can I create two functions source() without causing a name conflict? Don't they both have to be defined in the boost namespace, with the same signatures?
You would need a wrapper class for that case, or else only wrap one direction and use reverse_graph to get the other one (it does the flipping of sources and targets for you).
Also, I was wondering about an alternative approach. The interface could require member functions, and to provide them I would put third-party objects inside a wrapper class. The wrapper class would take the third-party object as a constructor argument, save it as a private data member, and expose the required interface in the form of member functions. This seems to allow for better encapsulation than the free functions approach. Does the free function approach have any advantages over the wrapper approach?
Probably not too many, but it is more elegant in some cases to be able to pass in a third-party graph type as is into Boost.Graph algorithms. -- Jeremiah Willcock