2011/5/8 Eric Niebler <e...@boostpro.com>:
> On 5/2/2011 6:18 PM, Thomas Heller wrote:
>> On Mon, May 2, 2011 at 12:54 PM, Eric Niebler <eric.nieb...@gmail.com> wrote:
>>> Phoenix is changing the following fundamental constants:
>>>
>>>  BOOST_PROTO_MAX_ARITY
>>>  BOOST_MPL_LIMIT_METAFUNCTION_ARITY
>>>  BOOST_PROTO_MAX_LOGICAL_ARITY
>>>  BOOST_RESULT_OF_NUM_ARGS
>>>

<snip>

> 3) After the patch is applied, Phoenix should be changed such that it
> includes proto_fwd.hpp and then acts accordingly based on the values of
> the constants. IMO, that should mean graceful degradation of behavior
> with lower arities, until a point such that Phoenix cannot function at
> all, in which case it should #error out.
>
> 4) Phoenix no longer needs to change BOOST_MPL_LIMIT_METAFUNCTION_ARITY
> and BOOST_RESULT_OF_NUM_ARGS, but BOOST_RESULT_OF_NUM_ARGS should be
> given the same treatment as (3).
>
> 5) MSM do the same.

Done for MSM.

> My pre-preprocessing work continues, and all EDSLs that use Proto will
> benefit from faster compiles. I'd like to thank Hartmut for his work on
> Wave and Thomas for getting me set up.

Thanks Eric. Unfortunately, the compile-time went up after the change
for VC. Not much but up. Example, CompositeTutorialEuml.
VC:
Before: 52s
Now: 57s (ignoring a first compile of 77s, statistical VC error)

g++ 4.4: Roughly the same time (21s / 21.7). Yes, much faster than VC, I know...

I suppose what I gain from preprocessing is lost from moving arity from 7 to 10.
It's not a big change but from previous burns, I know that the
slightest increase is enough to get some working code crash a VC
compiler at a user's machine, so I would not welcome another increase.

Thanks for the hard work anyway, I'm happy to get rid of my #define's.

Christophe
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Reply via email to