Re: [boost] Re: compile time member detection

From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2003-11-14 03:42:51

Brian McNamara wrote:
> On Thu, Nov 13, 2003 at 04:54:20PM -1000, David Abrahams wrote:
> 
>>"Brock Peabody" <brock.peabody_at_[hidden]> writes:
>>
>>>   template <typename T> T* clone(const T& t) {
>>>      return mpl::if_<
>>>         has_clone_function<T>,
>>>         use_clone_function,
>>>         use_copy_constructor
>>>      >::type::clone(t);
>>>   }
>>
>>This sort of thing really worries me in generic code, because the name
>>alone is not enough to identify the semantics.  It's one thing to say,
>>"if this thing has a clone function AND its signature contains a
>>special type that you can only know about if you also know about the
>>way my library looks for clone functions, then...", but when you just
>>check for a clone function as you do above, you're relying on everyone
>>having an agreement about the meaning of "clone".
>>
>>OK, so maybe clone is more likely to be agreed upon than the semantics
>>of most other member function names.  I hope you get my point, though.
>>It's easy to create really broken "generic" designs with these sorts of
>>tests.  You have to use them very carefully.
> 
> 
> "Me too."
> 
> In my opinion, "named conformance" is the right way to design most
> interfaces, whereas "structural conformance" (as above) is the wrong
> way.  What you really want to say is
> 
>    template <typename T> T* clone(const T& t) {
>       return mpl::if_<
>          is_clonable<T>,
>          use_clone_function,
>          use_copy_constructor
>       >::type::clone(t);
>    }

Why complicate things? Just make it a generic function that uses copy
construction by default, and rely on ADL and overloading instead of
class specialization.

    template<class T>
    T* clone(const T& t)
    {
       return new T(t);
    }

    Foo* clone(const Foo& t)
    {
       return t.clone();
    }

Restricting something to use a particular member function name is IMO a
bad idea..

-- 
Daniel Wallin