Re: [Boost-users] Some thoughts on Unary / BinaryFunctionConcept limitations

From: Stephen Gross (sgross_at_[hidden])
Date: 2005-09-12 12:21:14

> (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<typename Func, typename Ret, typename Arg>
struct special_UnaryFunctionConcept
{
  void constraints() { Ret (Func::*x) (Arg) = Func::operator(); }
};
==============

> (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