Gennaro Prota <[EMAIL PROTECTED]> writes: > --- David Abrahams <[EMAIL PROTECTED]> wrote: >> Gennaro Prota <[EMAIL PROTECTED]> writes: >> >> > On Sun, 08 Dec 2002 12:34:48 -0500, David Abrahams >> > <[EMAIL PROTECTED]> wrote: >> > >> > [snip] >> >>> // untested >> >>> #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1) >> >>> #define BOOST_WORKAROUND(symbol, test) \ >> >>> (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test) >> >> >> >>This will fail if "symbol1" is defined, won't it? >> > >> > Oops, due to the font used when reading mails from Yahoo, I thought >> > this was a typo for "symbol" :-s Yes, you are right. It wasn't >> > intended as a solution to >> > >> >>> b) "hides" possible problems in the (unlikely, granted) case that >> >>> X is undefined but X1 is and you write: >> >>> >> >>> BOOST_WORKAROUND(X, test) >> >>> >> >>> (the result "unexpectedly" depends on the expansion of X1). >> >> Actually, I tested my solution for that problem and it was OK. That's >> the reason I was pasting that long BOOST_NUMERIC_DEFINED_SUFFIX symbol >> to it: the idea was that probably nobody defines the >> __SUNPRO_CCBOOST_NUMERIC_DEFINED_SUFFIX symbol, for example. > > 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. >> 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. 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 # if !BOOST_WORKAROUND(SOME_COMPILER_MACRO1, == 1) # error whoops2 # endif 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. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost