Re: [boost] Review: Base from Member

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-08-07 09:15:49

On Tuesday 07 August 2001 09:26, you wrote:
> From: "Douglas Gregor" <gregod_at_[hidden]>
>
> > Without the ability for a user to specify the name of the data member
>
> (which
>
> > would require either macro tricks or a core language change), I think
>
> that
>
> > this particular idiom does not lend itself well to being translated
>
> into a
>
> > reusable, generic library.
>
> It certainly would be nice to have a nicely named member.  For some
> small classes it is not important, but in general a meaningful name is
> needed.  Fortunately, a meaningful name can be attached to the member by
> typedefing the base class and using the qualified access to the member.
> The user code would look like:
>
> class foo: base_from_member<bar_type> {
>     typedef base_from_member<bar_type> meaningful_name;
>
>     void fn() {
>         meaningful_name::member.whatever();
>     }
> };
>
> The cost is an extra line of code, but that is still a nice savings over
> an entirely separate class.  Using base_from_member also avoids the

I'm not seeing that it is a savings at all. If at each use we need towrite 
"meaningful_name::member" instead of "meaningful_name", how long before we 
have actually no savings? The above example could be hand-coded very easily:

struct base_initializer_bar {
  base_initializer_bar(const bar_type& b) : bar(b) {}

  bar_type bar;
};

As for savings, a rough count says:
        - Using the base_from_member approach requires ~80 characters of typing up 
front (to derive from the class and typedef it), plus another 8 characters 
for each use of the variable.
        - Hand-coding the approach requires ~120 characters of typing (creating the 
base_initializer_bar class and inheriting it).

Obviously the counts vary from instance to instance, but the savings here is 
negated if the member is accessed only five times.

> problem of the obfuscation that the hand-coded extra class causes: it
> appears that there is a an is-implemented-in-terms-of relation, which
> isn't really the intent.  Base_from_member makes the intent clear, which
> is just to work around an initialization ordering limitation.

If a generic class can be named to make the intent clear, so can a hand-coded 
one. The hand-coded version also has several advantages:
        - The fact that the idiom is used at all is confined to the base class list 
and the constructors
        - You can add the exact constructors (for base_from_member) that you 
require. The generic base_from_member cannot catch all possibilities (should 
each parameter be a ref/const ref/value?)
        - Might save on typing

> So overall, even though a perfect solution isn't available, I think that
> a base_from_member class would be the best of the alternatives, and
> would be a useful addition to boost.

        Doug