Re: [boost] C++11 Metaprogramming

Subject: Re: [boost] C++11 Metaprogramming
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-04-04 12:43:47

on Wed Apr 04 2012, Eric Niebler <eric-AT-boostpro.com> wrote:

> On 4/3/2012 10:20 AM, Dave Abrahams wrote:
>> 
>> on Sun Apr 01 2012, Olivier Grant <olivier.grant-AT-gmail.com> wrote:
>> 
>>> Hi Dave,
>>>
>
>>> That's going to be an interesting presentation. Here is a small piece of
>>> code that allows to generate a traits structure that determines if a call
>>> can be made on an object with a specific function name and specific
>>> arguments and return value :
>>>
>>> https://gist.github.com/2276393
>>> (compile with : g++ -std=c++0x -Wall -o has_callable has_callable.cpp)
>>>
>>> This was not possible in C++03, or at least not completely possible, and
>>> the code is much simpler with C++11 for the cases where it was possible as
>>> well.
>
> Well, there's this: http://tinyurl.com/85sv5sy [*]

Yes, but I think the OP was talking about detecting member function
callability.

>> Yep, I see.  However, I also have some questions about the utility of
>> such traits.  As I mentioned to Mathias, structural matching is always
>> susceptible to false positives.
>
> Unless I'm mistaken, you can't get my code to report a false positive.

I think you misunderstand what I mean by "false positive."

I mean that structural queries (like "can you call this function with
these parameters") are IME usually used as a concept check—which, when
the goal is not to cause an error, is used for the purposes of
dispatching to appropriate algorithm implementations.  However, a type's
/interface/ can always support a syntax that structurally resembles a
concept without supporting the semantics, or even without being able to
actually instantiate the operation

         struct looks_like_a_universal_function_object
         {
             template <class...Ts>
             void operator()(Ts&&...xs)
             {
                 std::swap(xs...);
             }
         };

This is strictly a binary function object, but its interface doesn't say
say.

> You can get it to fail to compile with an ambiguity error, but only if
> you go tinkering with extremely obscure language features. (E.g. by
> making an object callable by giving it an implicit conversion to a
> function pointer.)
>
> Anyway, the link describes a few cases in Proto where this trait is
> used, and others have found it useful.

OK, it looks like you're using the function object as a kind of
"policies class," and the trait makes it more convenient than it
otherwise might be to define such classes.  Since you tell the user
exactly how it will be interpreted and the user has full control over
the class' definition, this works out fine.  Yes, that's an important
use-case for TMP.  Thanks for clarifying.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com