Boost logo

Boost :

Subject: Re: [boost] How to detect if f() returns void or not?
From: Eric Niebler (eric_at_[hidden])
Date: 2009-12-15 16:31:20


Andy Venikov wrote:
> Eric Niebler wrote:
>>
>> http://www.boost.org/doc/libs/1_41_0/doc/html/proto/appendices.html#boost_proto.appendices.implementation.function_arity
>
>
> I gotta admit, this thing is amazing. I actually needed to implement a
> way to tell whether a type is an io manipulator (basically telling if
> calling T(ostream) is a well-formed expression), and was at a loss. I
> was about to post a question on comp.lang.c++ but suddenly came across
> this thread and your solution fit like hand in glove.

Great. Maybe this technique deserves to be more widely known.

> I do have a question though.
> In your "fununwrap2" class you define the typedef as
>
> typedef private_type const &(*pointer_to_function)
> (dont_care, dont_care);
>
> and dont_care constructor has ellipsis instead of an argument list.
>
> Why use dont_care at all? Why not define the pointer_to_function type as:
>
> typedef private_type (*pointer_to_function)
> (...);
>
> It seems to be working just as good.
> Or am I missing something?

I think it's me that missing something. The goal is to come up with the
worst possible conversion sequence so that our overload gets picked only
if there really is no other option. My thought was that using dont_care
makes the conversion sequence longer because not only does it involve an
ellipsis conversion, but it also involves a user-defined conversion (to
dont_care). But to my surprise, that seems not to be the case.

Consider this:

   struct dont_care {dont_care(...) {}};

   char fun(dont_care) { return 0; }
   int fun(...) { return 0; }

   int main()
   {
     fun(1);
     typedef char assert_[1==sizeof(fun(1))];
   }

For some reason, the overload that involves both an ellipsis conversion
*and* a user-defined conversion is actually preferred over the one that
involves just an ellipsis conversion. I don't understand that, but it
wouldn't be the first time that I was baffled by the C++ overloading rules.

Sometimes I think I'll never really know C++.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

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