Boost logo

Boost :

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

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.


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