|
|
Proto : |
Subject: Re: [proto] [phoenix][msm] proto limits increased to 10, phoenix broken on trunk (was: [phoenix] not playing nice with other libs)
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-05-08 12:51:24
2011/5/8 Eric Niebler <eric_at_[hidden]>:
> On 5/2/2011 6:18 PM, Thomas Heller wrote:
>> On Mon, May 2, 2011 at 12:54 PM, Eric Niebler <eric.niebler_at_[hidden]> 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 list run by eric at boostpro.com