Boost logo

Boost :

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-07-30 13:34:48

Here are my comments on the Base from Member utility:

I would like to see base_from_member refactored so that the programmer
need not be bothered with the unary, binary, etc. prefixes.

The ron_ name for the member variable provides no meaning. "member"
would be more suitable. Given an obvious name, there would be no reason
then to push a naming convention (the trailing underscore) on such a
basic class as this.

base_from_member should support a variety of constructor calls into the
member, e.g.:

struct A {
    typedef base_from_member<MemberType> bfm;
    A(): bfm(), other(bfm::member) {}
    A(int i): bfm(i), other(bfm::member) {}

To accomplish this, I propose this interface and implementation:

template <typename MemberType, int UniqueID = 0>
class base_from_member
  member() {}

 template<typename T1>
 base_from_member(T1 x1):
  member(x1) {}

 template<typename T1, typename T2>
 base_from_member(T1 x1, T2 x2):
  member(x1, x2) {}

 template<typename T1, typename T2, typename T3>
 base_from_member(T1 x1, T2 x2, T3):
  member(x1, x2, x3) {}

 MemberType member;

The real implementation would add more parameters, up to the standard
boost limit.

The intent with regard to breaking away from utility.hpp isn't clear.
If the intent is to decouple the utilities some day, it is important
that utility.hpp doesn't include base_from_member.hpp, since otherwise
removing the inclusion in the future could break working code.

Regarding documentation, the usage example should match with rationale.
It was confusing for me to read, because I expected the usage to show
the new and better way to code the example in the rationale section
using the boost class. It was startling to find an example quite a bit
more complex.

More specifically, the example should show the member variable being
passed by reference to the other constructor, since this is often best
practice and avoids the complexity of needing the this-> prefix for a
pointer. This complexity is better presented in a subsequent example,
so that too much new material is not presented at once.

In summary, my opinion is that the Base from Member utility should not
be accepted in its current form. The concept is good, but I think the
actual interface and implementation can be substantially improved
through the suggested refinements.

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