Re: [Boost-users] Some thoughts on Unary / BinaryFunctionConcept limitations
(1) The implementation of Unary and Binary (FunctionConcepts) assume that the return type is assignable ("r = f(arg)" tries to assign a value to r). But what if the return type is a reference? Won't the function concept fail to compile? Is this a bug?
That looks like a bug. Here's a challenge for you: how would you fix this bug?
In my own functor concept implementation, I used the function-pointer trick
to make it work:
==== CODE ====
template
(2) I'm implementing an NaryFunctionConcept for functors taking more than 2 arguments. The BOOST_CLASS_REQUIREx macro, however, appears to be limited to 4 types. This limits the NaryFunctionConcept to functors with up to two arguments. Is there a way to expand the BOOST_CLASS_REQUIREx macro to handle more than 4 types?
I'm sure there is a way. Can you think of a way to do it? Perhaps the boost preprocessor library would help.
Well, I was thinking that it BOOST_CLASS_REQUIREx for x > 4 could be added to the concept_check library in the same way that it is for x <= 4. Is this possible?
(3) I ran into a compiler problem when using BOOST_CLASS_REQUIREx; when any of the type macros have spaces or non-alphanumeric characters in them, the compiler reports an error. In the following example, I try to use the macro to require a UnaryFunctor taking a const std::string & and returning an int.
Yes, you need to create a typedef for such types. This restriction should be documented. I've checked in a fix to the docs.
Ok, gotcha. Interesting... Thanks, --Steve
participants (1)
-
Stephen Gross