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
