Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-17 11:18:13

--- In boost_at_[hidden], David Allan Finch <sarum_at_v...> wrote:
> jsiek_at_l... wrote:
> > I have a suggestion for the boost programming guidelines. As
> > boost members have pointed out in the past (most recently Dave),
it is
> > better to use free (non-member) functions over member functions in
> > public interfaces.
> I am probably a lone voice in the wilderness on but I
> view that Coplin's (?) original analysis of this problem
> is incorrect and hence his derived solution is incorrect
> to.
> His premises is that if you have a complex class you
> can't extend it because you do not have access to
> the fundamental fields. Hence it is better to have
> access to a smaller set of methods and
> have complex functionality at namespace level.
> This is an incorrect (IMHO) conclusion. If you
> look at any real world physical implementation
> of a system, you will find that the complex functionality
> is rapped up in a new level of system. I.E. controllers.
> One of the classic problems that is used to show
> why there is a problem is extending the String
> class. IMHO the problem is that the String
> class is to complex and should have been implemented
> as a controller of a StringBuffer. You would then
> write your own String Manipulator or extend String
> to change the String Buffer how you wished it to be
> modified.

I'm not sure that I understand fully all the pros and cons on this
subject. However, the last paragraph here is precisely why I'm not
sure that I agree with the original hypothesis. The string class as
an example is not a very good example. It isn't difficult to
extend. It's just problematic to extend it via inheritance, which is
what Jeremy suggested was the only solution. Instead, you extend it
through free standing functions. This is *precisely* what the STL
algorithms do, though they were carefully constructed to be generic
enough to extend a large class of objects instead of a single object

The inheritance/wrapper (containment) approaches are only appropriate
if you actually need to extend the class by adding data or need to
use the derived type polymorphically. Neither of these cases are
going to be solved by preferring free standing functions over member
functions to begin with.

I'm not at all against using free standing functions, but I've yet to
be convinced that we should prefer them over member functions.

William Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at