On 9/14/2011 6:57 PM, Joel de Guzman wrote:
On 9/14/2011 6:32 PM, Thomas Heller wrote:
Unfortunately this trick doesn't hold for fusion as it is the other way around there, the _c functions are implemented in terms of their non-_c counterparts. (FWIW, i think that here lies a potential optimization possibility for fusion).
Patches always welcome ;-)
Now I recall, I was merely following MPL. I took a look at MPL and it's done this way too. See (at.hpp): template< typename BOOST_MPL_AUX_NA_PARAM(Sequence) , typename BOOST_MPL_AUX_NA_PARAM(N) > struct at : at_impl< typename sequence_tag<Sequence>::type > ::template apply< Sequence,N > { BOOST_MPL_AUX_LAMBDA_SUPPORT(2,at,(Sequence,N)) }; template< typename Sequence , BOOST_MPL_AUX_NTTP_DECL(long, N) > struct at_c : at_impl< typename sequence_tag<Sequence>::type > ::template apply< Sequence,mpl::long_<N> > { }; And, thinking about this, it would break backward compatibility if we change the API for the extension mechanism to accept plain integral constants instead. The gains you see in using at_c happens when you start to do some computation. E.g. at_c<a + b> is faster that at<mpl::plus<a, b> >. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com