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