Re: Review: Base from Member

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

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

OK.

> 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