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
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> 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.
[...]
>Would you kindly post what you think the correct form
>of BOOST_WORKAROUND should be?
Er... let me say again that we are talking about quibbles, in the
sense that it's highly unlikely that one incurs in a macro like
_MSC_VER1, __SUNPRO_CC1 and the like (the only case I can think of
where that would happen is that such a macro is introduced, for some
unknown reason, by the compiler vendor in some future version of an
existing compiler, and even in such a remote case one can change '1'
to something else, provided that he remembers that the implementation
of BOOST_WORKAROUND has that problem). Also, the objection about
creating a too large pp-number is moot. That's why I presented my
initial post as a simple set of "thoughts", not real objections. Sort
of "dissection" of the current code. The most important point was the
one about dependency on cat.hpp. 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 do know that for us keen on C++ programming your form is more
seductive, but I think we should resist :-) 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.
Genny.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
