|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-11-13 21:54:20
"Brock Peabody" <brock.peabody_at_[hidden]> writes:
>> Not sure about that part. I mean, I know it would be useful, but I'm
>> not certain whether it's useful *enough*. I just have no opinion.
>
> So far I'm only checking for member functions, but I think I'd have used
> this technique a lot in the past if it had been available to me.
>
> It would take too much space to describe what I'm doing with it, but I
> remember a compelling example that was in CUJ a while back (paraphrased):
>
> struct use_copy_constructor {
>
> template <typename T> static T* clone(const T& t) {
>
> return new T(t);
> }
> };
>
> struct use_clone_function {
>
> template <typename T> static T* clone(const T& t) {
>
> return t.clone();
> }
> };
>
> template <typename T> T* clone(const T& t) {
>
> return mpl::if_<
>
> has_clone_function<T>,
> use_clone_function,
> use_copy_constructor
>
> >::type::clone(t);
> }
This sort of thing really worries me in generic code, because the name
alone is not enough to identify the semantics. It's one thing to say,
"if this thing has a clone function AND its signature contains a
special type that you can only know about if you also know about the
way my library looks for clone functions, then...", but when you just
check for a clone function as you do above, you're relying on everyone
having an agreement about the meaning of "clone".
OK, so maybe clone is more likely to be agreed upon than the semantics
of most other member function names. I hope you get my point, though.
It's easy to create really broken "generic" designs with these sorts of
tests. You have to use them very carefully.
>> > These types of inspection can provide very nice resolutions to
>> > problems that otherwise require more intrusive solutions like
>> > derivation or specialization.
>>
>> Occasionally.
>
> I think people will begin to see more opportunities to use this type of
> introspection, especially with the advent of tools like enable_if.
I'm a bit worried about that very thing.
-- 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