This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/14608] <iostream.h> nukes isfinite macro from <math.h>
- From: "gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Mar 2004 19:52:15 -0000
- Subject: [Bug libstdc++/14608] <iostream.h> nukes isfinite macro from <math.h>
- References: <20040316182307.14608.zack@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From gdr at integrable-solutions dot net 2004-03-16 19:52 -------
Subject: Re: New: <iostream.h> nukes isfinite macro from <math.h>
Short answer for this PR: Use -D_GLIBCXX_USE_C99_MATH if you want to
retain C99 random bits consistently.
Longer answer:
"zack at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| I will attach two test cases to this bug. The first test case was
| provided to me by a customer; it is a cut-down version of a larger
| piece of code that did need both <math.h> and <iostream.h>. The
| observed problem is that if both these headers are included (in
| either order) in the same translation unit, the isfinite macro (part
| of C99) is not available to subsequent code. If only <math.h> is
| included, then isfinite is available.
The bug is that isfinite() is at all available *as macro*, when
<math.h> is included. But, that is a general problem in that we don't
have control over <math.h> and so we don't remove sneaky macros as we
should all the time.
First of all, C++ explicitly permits any standard header that is not
inherited from C to include any other standard header -- that is
hardly avoidable. <iostream.h> is not a standard header but is
provided as a courtesy (see appendix D of the C++ standard) and is, in
fact, an inclusion of <iostream> followed by a series of
using-declarations -- as is done for C inherited headers <xxx.h> as
mandated by the C++ standard. <iostream> (transively) includes
<cmath> for whatever reasons. <cmath> turn functional macros into
functions, and by default provides only C90 functions.
However, you may specify -D_GLIBCXX_USE_C00_MATH if you want to retain
C99 random bits.
| The second test case is the workaround that I found for GCC 3.3.3.
| It does not work with GCC 3.4, even with the obvious s/GLIBCPP/GLIBCXX/.
|
| It should be noted that HPUX's libc does not implement all of C99,
| but it *does* provide all of the C99 math functions - but isfinite()
| and friends are only macros (which is allowed by C99). I don't know
| what the C++ standard specifies in this area but it seems to me that
| QoI dictates that C++ programs be able to use all the
| system-provided library facilities.
Discussing "dictated" behaviour without looking at what the C++
standard says is a good recipe for frustration and waste of time.
The C++ committee is considering adding -- to the first Technical
Report (not a standard in its strict sense) -- modified versions of
the myriad of functions C99 added to C90. PJ. Plauger made a report
early in 2002 and followed up with
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1503.txt
and more corrections in subsequent mailings.
Turning C99 sneaky functional macros into plain functions are general
requirements of C++ and also recommended in the above proposal.
The implementation of V3 is in adequation with those recommandations.
I propose to close this PR. The only bug here is that we don't remove
macros consistently, but that is a known problem we don't have a
solution for right now.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608