On Thu, Jul 29, 2010 at 1:54 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
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.
I implemented phoenix::at_c the same way as it was done with phoenix2. Have a look here: https://svn.boost.org/trac/boost/browser/sandbox/SOC/2010/phoenix3/boost/pho... I think the reason why it was (and is done) this way, is to supply N as a template parameter, not a parameter to the lazy function.