On 5/2/2011 6:18 PM, Thomas Heller wrote:
On Mon, May 2, 2011 at 12:54 PM, Eric Niebler <eric.niebler@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
IMO, Phoenix shouldn't be touching these. It should work as best it can with the default values. Users who are so inclined can change them.
Eric, This problem is well known. As of now I have no clue how to fix it properly. <snip>
The Proto pre-preprocessing work on trunk has progressed to the point where compiling with all the arities at 10 now compiles *faster* than unpreprocessed Proto with the arities at 5. So I've bumped everything to 10. A few things: 1) Phoenix is now broken. My Proto work involved pruning some unnecessary headers, and Phoenix isn't including everything it needs. Thomas, I'll leave this for you to fix. 2) Phoenix is actually setting Proto's max arity to 11, not to 10. I think this is unnecessary. Locally, I un-broke Phoenix and ran its tests with 10, and only one test broke. That was due to a bug in Phoenix. I'm attaching a patch for that. 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. 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. -- Eric Niebler BoostPro Computing http://www.boostpro.com