Re: [boost] Formal Review Request: TypeErasure

Subject: Re: [boost] Formal Review Request: TypeErasure
From: Larry Evans (cppljevans_at_[hidden])
Date: 2012-06-27 11:48:24

On 06/26/12 14:18, Steven Watanabe wrote:
> AMDG
> 
> On 06/26/2012 11:41 AM, Larry Evans wrote:
>>
>>   */libs/type_erasure/doc/html/boost_typeerasure/conceptdef.html
>>
>>     states:
>>
>>       The template parameters of the concept may involve placeholders.
>>
>>         * Each template argument may be a cv and/or reference
>>           qualified placeholder type.
>>
>>         * If a template argument is a function type, its arguments and
>>           return type may be cv/reference qualified placeholders.
>>
>>     but, because of the 'may's it doesn't require a placeholder.
>>
> 
> That's correct.  The errors that you're
> getting stem from a different cause.  The
> library doesn't actually require any placeholders,
> although it isn't terribly useful without them.
> 
[snip]

>> gcc4.8 fails to compile it and gives a very obscure error message
>> containing:
>>
>> ../../../boost/type_erasure/call.hpp:530:89:   required from 'typename
>> boost::type_erasure::detail::call_result<Op, void(U0&)>::type
>> boost::type_erasure::call(const Op&, U0&) [with Op = concept<>; U0 =
>> int; typename boost::type_erasure::detail::call_result<Op,
>> void(U0&)>::type = void]'
>> concept_ph.cpp:84:5:   required from here
>> ../../../boost/type_erasure/detail/get_signature.hpp:23:5: error:
>> incomplete type 'void' used in nested name specifier
>>      BOOST_TYPEOF_NESTED_TYPEDEF_TPL(nested, &Concept::apply)
>>      ^
>>
>> which seems to support the position that some placeholder is required
>> in the concept's template arguments, AFAICT.
>>
> 
> For some reason, gcc tends to make errors with call
> point to BOOST_TYPEOF.
> 
> Anyway, I can compile the following just fine with
> MSVC 10.
> 
> int i = 0;
> call(binding<incrementable<int> >(mpl::map0<>()),
>     incrementable<int>(), i);
> // i = 1

But, AFAICT, that call doesn't have a concept as the 1st arg.
To make the above call like the ones in my attached file, this
would have to be:

  call(incrementable<int>(), i);

The attached has that, and when it's compiled, it produces errors
similar to the one previously mentioned here:

http://article.gmane.org/gmane.comp.lib.boost.devel/232109

more specifically, the errors include:

../../../boost/type_erasure/detail/get_signature.hpp:23:5: error:
incomplete type 'void' used in nested name specifier
     BOOST_TYPEOF_NESTED_TYPEDEF_TPL(nested, &Concept::apply)
     ^

However, now I realize that's probably because there's no any in
the argument list, a flaw you mention in the a) problem below.
So, I'm inferring from your call example, which includes
the binding<...>(...) arg, that somehow an any arg provides
something like a binding?

It would help me if more documentation on the args to
call were supplied.  Initially, I had thought call just
used the 1st arg(the concept) for it's type, and then just
called that type's static apply with the remaining args
after, maybe, substituting the placeholders with ...
Hmm... now I'm not sure what I was thinking, but what's
becoming clearer to me is I need some more clarification
on how call works because I'm not having much success
in using it so far :(

> 
> The problems with your code are:
> 
> a) call(concept<int>(), y)
>   - The library cannot deduce the the
>     binding because none of the arguments
>     is an any.
> b) call(concept<_self>(), a_any)
>   - concept<_self> is not part of the requirements
>     of a_any.
> 
> In Christ,
> Steven Watanabe
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>