[boost] Re: compile time member detection

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