$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-11-14 09:17:41
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Brian McNamara
> "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);
> }
After thinking about it some more, I find myself agreeing with you and Dave.
Is there a good use then for member detection, other than types?
> where is_clonable is a metafunction which tests not only the structural
> conformance (as suggested above), but also named conformance. Some
> human should have to explicitly say that T is indeed a clonable (e.g. it
> has the right semantics to match the concept). This can be done in a
> variety of ways, the most popular probably being via specialization:
I like to use inheritance over specialization because the trait is then
passed down to children automatically:
struct clonable {};
template <typename T> T* clone(const T& t) {
return mpl::if_<
is_base_and_derived<clonable,T>,
use_clone_function,
use_copy_constructor
>::type::clone(t);
}
Another possibility would be to use member type detection:
struct Foo { typedef library::clonable clonable; ...};
A class would be clonable if it had a typedef named clonable of type
library::clonable. This would be inheritable too, but you could more easily
'shut it off' in derived classes.
Brock