Re: [boost] Boost Graph Library: why are `source()`/`target()` non-member functions?

Subject: Re: [boost] Boost Graph Library: why are `source()`/`target()` non-member functions?
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2013-04-22 17:54:18

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