Boost logo

Boost :

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-11-14 11:01:06

There are a number of recent messages on this thread, and I've chosen to
reply "in batch".

Daniel Wallin:
> 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.

This strategy uses structural conformance. I want named conformance.
(Named conformance is not as susceptible to accidental conformance.)

Brock Peabody:
> Restricting something to an exact signature is a real limitation of this
> technique. It would not even work with:
> struct foo {
> foo* clone() const;
> };
> But, that's all I could squeeze from the compiler for the time being.

Indeed. "Detecting" is much harder than "ensuring/asserting". See
Section 3 of "Static Interfaces in C++" (
for some discussion. However, with the discovery of SFINAE, it may be
possible to detect "inexact" signatures nowadays.

Brock Peabody:
> 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);
> }

I do too, but the moment I mention this, people on on this list jump
down my throat shouting "intrusive methods! intrusive!" They are right;
template specialization lets you declare that (e.g.) "T isa clonable"
even if you are not the author of T (and even if T is a primitive type
like "int"). My usual strategy is to code a template metafunction which
checks both "named conformance via tag-inheritance" and "named
conformance via specialization" so that you can do it either way, and
get the best of both worlds.

Brock Peabody:
> 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.

This is too susceptible to accidental conformance; it is a "structural"
rather than a "named" approach.

Dave Abrahams:
> Incidentally, the evolution working group is considering various
> ideas for adding concept checking to the language, most of which
> center around structural, rather than named, conformance.

So would there be interest in a boost library that does named
conformance checking? Along the lines of "Static Interfaces in C++"
(see above) but using more current "technology"?

-Brian McNamara (lorgon_at_[hidden])

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