Boost logo

Boost :

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

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