From: David Abrahams (dave_at_[hidden])
Date: 2002-12-08 13:57:24
Gennaro Prota <gennaro_prota_at_[hidden]> writes:
> On Sun, 08 Dec 2002 12:34:48 -0500, David Abrahams
> <dave_at_[hidden]> wrote:
>>> // 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, 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
# if !BOOST_WORKAROUND(SOME_COMPILER_MACRO1, == 0)
# error whoops2
So now I guess I really don't understand the preprocessor.
> just as an (untested) way to avoid the dependency on the preprocessor
> library. It is exactly the same of the current implementation, except
> that uses BOOST_JOIN instead of BOOST_PP_CAT.
BOOST_PP_CAT has several workarounds for broken compilers, and I
wanted to get it right first before worrying about that particular
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk