On Sun, 08 Dec 2002 15:45:39 -0500, David Abrahams <[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes: >> Well, there's no problem with __SUNPRO_CCBOOST_NUMERIC_DEFINED_SUFFIX, just >> with __SUNPRO_CC1. > >We seem to be talking past one another. I've been trying to tell you >that preventing expansion into __SUNPRO_CC1 was the very reason I used >BOOST_NUMERIC_DEFINED_SUFFIX. Ah! Are you saying you think BOOST_NUMERIC_DEFINED_SUFFIX may remain unexpanded? Indeed, as far as I understand the preprocessing, it always becomes 1. >>> Well, then I tested your solution and it was also OK on all the >>> compilers I have on my machine: >>> >>> # include <boost/config.hpp> >>> >>> #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1) >>> #define BOOST_WORKAROUND(symbol, test) \ >>> (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test) >>> >>> # define SOME_COMPILER_MACRO1 0 >>> >>> # if BOOST_WORKAROUND(SOME_COMPILER_MACRO, > 0) >>> # error whoops >>> # endif >> >> As I said, when SOME_COMPILER_MACRO1 is defined but SOME_COMPILER_MACRO isn't >> then the result depends on the expansion of SOME_COMPILER_MACRO1 (and possibly >> on the test, of course). In this case the condition of the #if becomes: >> >> (0 && SOME_COMPILER_MACRO > 0) >> >> and then, of course >> >> (0 && 0 > 0) >> >> Now, try defining >> >> #define SOME_COMPILER_MACRO1 5 >> >> and change the test e.g. to <= 1200 > >Sure, I did. I also had a test there which you snipped from your >email. Let me explain again what I meant: the reason why your example doesn't trigger the #error is that you define SOME_COMPILER_MACRO1 to zero (and because of the test ">0"). Actually, you "fall" into using SOME_COMPILER_MACRO1 but, luckily, the whole test yields false anyway. To have an unexpected #error I suggested you to try: #define SOME_COMPILER_MACRO1 5 #if BOOST_WORKAROUND(SOME_COMPILER_MACRO, <= 1200) # error whoops #endif >Why don't you run some tests yourself? Try this: > > # include <boost/config.hpp> > > #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1) > #define BOOST_WORKAROUND(symbol, test) \ > (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test) > > # define SOME_COMPILER_MACRO1 1 > > # if BOOST_WORKAROUND(SOME_COMPILER_MACRO, > 0) > # error whoops > # endif Yeah! You have no error here because after all the macro expansions on the #if condition you have (1 && SOME_COMPILER_MACRO > 0) but then the undefined identifier SOME_COMPILER_MACRO is replaced with zero! That's why I suggested to change the test. > # if !BOOST_WORKAROUND(SOME_COMPILER_MACRO1, == 1) > # error whoops2 > # endif Well, here you just end up with !(11 && 1 == 1) so no error either. > int main() > { > return 0; > } > > >> [...] >>> BOOST_PP_CAT has several workarounds for broken compilers, and I >>> wanted to get it right first before worrying about that particular >>> dependency. >> >> Yeah, I noticed that. I don't know what problems do they solve >> though so I'm not sure if they are needed in the case of >> BOOST_WORKAROUND. Maybe they have just to do with passing empty >> arguments? > >We'll have to ask Paul I guess. However, empty arguments are a very >real concern for the problem at hand. The precondition is that the first argument of BOOST_WORKAROUND must be either undefined or expand to something, i.e. you can't use for instance this #define X so I don't see any macro invocation where there's an empty sequence of tokens used as argument. Do you? Genny. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost