Re: [Boost-users] [lambda][phoenix] make lambda/phoenix play well with std::complex, imag, real, abs, etc.

18 Jun 2010

      On Mon, Jun 7, 2010 at 12:52 AM, Joel de Guzman
 wrote:
...
On 6/7/10 3:42 PM, Alfredo Correa wrote:
...
On Sun, Jun 6, 2010 at 4:41 PM, Joel de Guzman
  wrote:
...
Is there a reason why you are not using plain phoenix::function(s)
for this?
good point, I am still phoenix-challenged I guess. I got driven by the
"Composite" example in the manual.
This is the alternative implementation using phoenix::function:
namespace boost{namespace phoenix{
struct real_impl{
    template<typename Arg>  struct result{
        typedef double type; //can be generalized
    };
    template<typename Arg>
    typename result<Arg>::type
    operator()(Arg z) const{
        return real(z);
    }
};
function  real_; // "real" as name doesn't work
}}
int main(){
       std::complex<double>  z(1.,2.);
       cout<<  real_(arg1)(z)<
which works.
...But there is a problem it seem that I can not call "real_" as
"real", so the resulting syntax is degraded.
(Either I have to call the phoenix::function real_ or put std::real in
the operator())
It seems that the overload get confused. Is there a way to go around this?
(my poorly written first version --with no phoenix::function-- at
least didn't have this limitation)
Good point. Well, you can make real_ and friends use the extension
mechanism as before, then use functions for all else.
I understand the underscore is necessary for reserved keywords, but
using it for everything is a pity.
So I stick with the solution that allows the same phoenix and (rest
of) C++ the same name.

In fact I realized that if I need any function (from example in std
cmath) it is good to define the following macro to "register" existing
functions, to be used in phoenix expressions.

#include
#include 
/// Extends any endomorphic function as a phoenix function,
endomorphic in the sense that the input and output are of the same
type
#define BOOST_PHOENIX_REGISTER_ENDOMORPHISM(FN) \
namespace boost{ \
namespace phoenix{ \
	struct FN##_eval{ \
		template  struct result{typedef
typename boost::mpl::at_c::type type;}; \
		template  static RT
eval(Env const& env, Arg_ const& arg_){ \
			return FN(arg_.eval(env)); \
		} \
	}; \
	template <typename Arg_> \
	typename boost::enable_if_c::value, \
		actor::type> \
	>::type \
	FN(Arg_ const& arg_){ \
		return compose(arg_); \
	} \
}}

and then register any arbitrary function (this solution work if the
input/output type are the same. maybe with upcoming decltype we can do
better).

BOOST_PHOENIX_REGISTER_ENDOMORPHISM(cos);
BOOST_PHOENIX_REGISTER_ENDOMORPHISM(cosh);
BOOST_PHOENIX_REGISTER_ENDOMORPHISM(exp);
BOOST_PHOENIX_REGISTER_ENDOMORPHISM(log);
BOOST_PHOENIX_REGISTER_ENDOMORPHISM(log10);
...
This could be useful to make phoenix support a large portion of STL
(in this case cmath), I don't know if it is planned. Also there is no
necessity of the underscore.

Note two things:
1) I had to put an "enable_if_c" in order to avoid huge error messages
when the function is not really defined outside Phoenix. When the
function is not defined then the 'return FN(...)' line get confused
with the phoenix function with the same name.
2) I have a confusion with the namespaces, the phoenix function (e.g.
"cos") is in the namespace boost::phoenix which is good because the
function is resolved correctly most of the time. but the real function
(e.g. "std::cos") has no information about the namespace, which is
good but I guess sometimes we need need to be specific of the
namespace of the function we are trying to register. But adding the
namespace will break the macro. One alternative is to add a second
parameter to the macro so
BOOST_PHOENIX_REGISTER_ENDOMORPHISM(std::cos, cos); //first the fully
qualified name, second the boost::phoenix
the other possibility is to try to define the phoenix function in the
same namespace as the original function.
The fact that a function with the same name can appear in different
namespaces and the fact that there no concept of namespace in phoenix
then it seems the last possibility is the only general one.

Thanks,
Alfredo