This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
PATCH (abandonment): Apply Nathan's macro trick
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Fri, 18 Apr 2003 01:54:04 -0500 (CDT)
- Subject: PATCH (abandonment): Apply Nathan's macro trick
- Reply-to: rittle at labs dot mot dot com
> This re-expression of my posting is so elegant, I wonder if the
> names are still appropriate. Maybe the first three names should be
> _GLIBCXX_IF_0, _GLIBCXX_IF_1, and _GLIBCXX_IF, and should appear in
> a more generic header.
Sorry Nathan. You had a great idea in both theory and practice; and I
too worked on tweaking it for a while before seeing that it doesn't
really work in the exact context we have. I have no intention on
changing the context (details below).
OK, if we had a collection of macros with known value 0 or 1 (as you
displayed when you posted the technique), then your technique works as
advertised. The third state (of no defined value at all), in fact
can't be supported by any means I see. Unfortunately, our
configuration currently defines a macro to 1 if a feature is available
or leaves it completely undefined if not available (this is standard
autoconf-style AFAIK).
Of course, we all know that `#if XXX' handles XXX with value 0 or not
defined in an identical manner. Inside a macro expansion, it
obviously works quite differently. Zack is the CPP expert and he said
it (where it was logically ``#if X \ Y \ #endif'' defined in a macro)
can't be done. I now believe him for the general case that we have. ;-)
Regards,
Loren