Re: [boost] [phoenix] compile-time performance

Subject: Re: [boost] [phoenix] compile-time performance
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-09-14 07:27:32

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