Boost logo

Boost :

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):

        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 >

        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> >.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at