|
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
>>"un"-----------------------^
>
> 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] * 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