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

Subject: Re: [Boost-users] [lambda][phoenix] make lambda/phoenix play well with std::complex, imag, real, abs, etc.
From: alfC (alfredo.correa_at_[hidden])
Date: 2010-06-14 02:55:31

On Jun 7, 12:52 am, Joel de Guzman <j..._at_[hidden]> wrote:
> On 6/7/10 3:42 PM, Alfredo Correa wrote:
>
>
>
> > On Sun, Jun 6, 2010 at 4:41 PM, Joel de Guzman
> > <j..._at_[hidden]>  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_impl>  real_; // "real" as name doesn't work
> > }}
> > int main(){
> >    std::complex<double>  z(1.,2.);
> >    cout<<  real_(arg1)(z)<<endl;      
> >          return 0;
> > }
>
> > 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.

nice to see that I found the workaround before knowing about the
limitation.
Now, that seems also to be the case for all functions (for example in
std::) for which we need a phoenix counterpart with the *same name*
(with no underscore).

> Duly noted. In phoenix3, we'll have an easy way to have nullary
> functions which do not require ().

interesting. but I don't see how this can be applied to these
examples.

Thanks,
Alfredo