Subject: Re: [boost] [preprocessor] badly formed constant expression on Sun
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-04-13 16:07:20
On Fri, Apr 13, 2012 at 12:51 PM, lcaminiti <lorcaminiti_at_[hidden]> wrote:
> Paul Mensonides wrote
> > On Tue, 03 Apr 2012 19:27:40 -0700, lcaminiti wrote:
> >> Is (BOOST_PP_VALUE) / 1000000000UL not a valid constant expression on
> >> Sun 64-bits machines?
> > 32 vs. 64-bit shouldn't make a difference to the mechanism. I suppose it
> > might matter if something was less than 32-bit.
> >> I can't reproduce this error on my Sun C++ compiler installed on 32-bit
> >> Ubuntu Linux... so maybe this is about the actual Sun machine and not
> >> the Sun compiler... However, all Boost.Preprocessor tests pass on Sun...
> >> Any suggestion?
> >> Thanks a lot.
> >> --Lorenzo
> > I have no idea what the problem is (and I don't have access to the
> > compiler/architecture to figure it out). What's BOOST_PP_VALUE defined
> > as?
> It's a bit different for me to be sure about what was going on but I think
> the following caused the error:
> # define BOOST_PP_ITERATION_PARAMS_1 \
> (3, (0,
> BOOS_PP_SUB(BOOST_FUNCTIONAL_OVERLOADED_FUNCTION_CONFIG_OVERLOAD_MAX, 2), \
> # include BOOST_PP_ITERATE() // Iterate over function arity.
> The issue goes away if I remove the PP_SUB from within the PARAMS_1
> definition (that's how I worked around the issue, I iterate 2 to MAX and
> then SUB 2 from within the iteration frame).
> Is that expected or it's a bug in the Sun pp macro expansion? This issue
> only happened on Sun...
Did you try simply *_OVERLOAD_MAX - 2? The parameters supplied via
ITERATION_PARAMS_x are (documented to be) evaluated parameters, so I should
think the aforementioned should work (of course, I would think SUB should
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk