Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-09 08:49:01

Gennaro Prota <gennaro_prota_at_[hidden]> writes:

> I apologize for the tardy reply but, as it often happens, it was late
> night here when I received your post.
> On Sun, 08 Dec 2002 18:20:27 -0500, David Abrahams
> <dave_at_[hidden]> wrote:
>>Gennaro Prota <gennaro_prota_at_[hidden]> writes:
>>> Actually, you "fall" into using
>>> SOME_COMPILER_MACRO1 but, luckily, the whole test yields false
> I seize the opportunity to improve my English: what is "un"? An
> exclamation? I guess it means ironically: "Well, what a luck!", but I
> would like a confirmation... you may well see how unhinged my English
> is :-s.

No, I just meant that a falsely succeeding test is very _unlucky_.

> Implementing it as
> #define BOOST_WORKAROUND(symbol, test) \
> ( BOOST_JOIN(symbol, 1) && symbol test)
> solves that problem but we should see if BOOST_JOIN actually works on
> all the supported compilers (in other words, if we don't need the
> workarounds that are in cat.hpp).
> Probably with some further machinery it is possible to end up with
> something like BOOST_ALWAYS_UNDEFINED(unexpanded symbol argument)_1
> (but I've not tried), however as I said, all things considered, I
> would just use
> #define BOOST_WORKAROUND(symbol, test) ((symbol != 0) && symbol test)

I'd like to change that as follows:

  #define BOOST_WORKAROUND(symbol, test) ((symbol != 0) && (symbol test))

Just in case.

> I do know that for us keen on C++ programming your form is more
> seductive, but I think we should resist :-)

I agree.

> What this discussion shows is that there's no way (at least we
> didn't find any) to emulate the preprocessor defined operator, even
> if we limit ourselves to testing macros that (if defined) expand to
> preprocessing-numbers.

Sounds good to me.

                       David Abrahams
   dave_at_[hidden] *
Boost support, enhancements, training, and commercial distribution

Boost list run by bdawes at, gregod at, cpdaniel at, john at