Re: [boost] [phoenix3] at_c

Subject: Re: [boost] [phoenix3] at_c
From: Joel de Guzman (joel_at_[hidden])
Date: 2010-07-28 19:54:26

On 7/29/10 3:51 AM, Denis Taniguchi wrote:
> Hi,
>
> I think that a reasonable implementation of at_c for the new phoenix3
> could be:
>
> #pragma once
>
> // boost headers
> #include<boost/fusion/include/at.hpp>
> #include<boost/phoenix/function.hpp>
> #include<boost/type_traits/remove_reference.hpp>
> #include<boost/type_traits/remove_const.hpp>
>
> // std headers
> #include<algorithm>
> #include<iostream>
>
> namespace boost
> {
>    namespace phoenix
>    {
>      template<int N>
>      struct at_impl
>      {
>        template<class Signature>
>        struct result;
>
>        template<class This, class Arg>
>        struct result<This(Arg)>
>        {
>          typedef typename boost::fusion::result_of::at_c<
>            typename boost::remove_reference<Arg>::type
>          , N
>          >::type type;
>        };
>
>        template<class Arg>
>        typename boost::result_of<at_impl<N>(Arg&)>::type
>        operator()(Arg&arg) const
>        {
>          return fusion::at_c<N>(arg);
>        }
>      };
>    } // namespace phoenix
> } // namespace boost
>
> If that piece of code is valid (I have tested but I'm not sure if that's
> the right way to do it) how would boost::phoenix::at_c be implemented?
> In phoenix2 at_impl was a eval so at_c was a template inline function.
> Best regards,

I'm not sure why phoenix2 implemented it using the extension
mechanism instead of a plain phoenix function. In phoenix3,
I suggest making it a phoenix function. Oh, and I also suggest
dealing with const/non-consts and returning references as well.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net