Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-14 11:23:28


Brian McNamara <lorgon_at_[hidden]> writes:

> 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.)

Just a note: customization by specializing a class template with a
nested static member function produces named conformance.

Sometimes, I think named conformance is too heavyweight. Is that
just a side-effect of the way the language is defined?
http://www.boost-consulting.com/writing/qn.html shows a proposal I
made to, in part, fix that problem.

> 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!"

YES! "INTRUSIVE METHODS! INTRUSIVE!" ;^)

> They are right;

YES! ;o)

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

Not really, if library::clonable is a type with a prescribed
meaning. If it's in the contract that by using it you have a certain
semantic intention, it's fine.

> 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"?

I think you should look at the concept-checking papers in the pre-Kona
mailing. What you're proposing is not really a response to that.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk