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: Max Moroz (maxmoroz_at_[hidden])
Date: 2013-04-22 17:46:15

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?

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?

Max