Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-07-31 21:20:45

on 7/30/01 1:34 PM, Ed Brey at edbrey_at_[hidden] wrote:

> 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.

OK. (The "ron_" name was the last way of honoring the discoverer of the

> 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
> {
> protected:
> template<>
> base_from_member():
> member() {}

Is this (a non-specializing template declaration with no parameters) legal?

> 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;
> };

+ Only need one class template
+ Helps if the receiver class needs several construction configurations
    of the base-from-member for different (receiver) constructors
- Cannot work if the compiler doesn't support member templates
- C++ syntax gives no way of specifying the template parameters of a
    constructor member template (unlike any other kind of template). It
    depends on argument deduction only. Could this be a potential problem?

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

I wonder if the pre-processor library can help in automating this?

> 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.

I originally had the new templates in <boost/utility.hpp> proper. Other
people had suggested splitting the utility stuff up. As you see, I started
to do some decoupling, but I stopped so I wouldn't have to change too much
of my own code. (Ironic since I warned others in the past to not worry
about backwards-compatibility with their own interim versions.) I initially
didn't do this because of what you just did; critiques of the decoupling
plans get marked with the main stuff of the review.

> 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.

Actually, the rationale example needs the "this->" to work.

> 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.

Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

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