This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ISO C++ and C99 features
- To: llewelly at dbritsch dot dsl dot xmission dot com, martin at loewis dot home dot cs dot tu-berlin dot de
- Subject: Re: ISO C++ and C99 features
- From: Mike Stump <mrs at windriver dot com>
- Date: Mon, 19 Jun 2000 12:40:59 -0700 (PDT)
- Cc: gcc at gcc dot gnu dot org, nathan at codesourcery dot com
> Date: Sun, 18 Jun 2000 16:40:18 -0600 (MDT)
> From: llewelly@dbritsch.dsl.xmission.com
> <iostream> contains std::clog.
> I do not have a copy of the C99 standard, but I seem to remember
> c99 <complex.h> contains a clog() function (for complex
> logarithms). Is this a problem?
First, I think it is pointless to talk about this too much, unless
someone wants to implement this now. Otherwise, we just have to talk
about it later when someone does implement it. Also, this is best
talked about in comp.std.c++ I bet, that way, one can get some idea as
to what other implementers are doing (and to prompt the committee to
think about the issue).
Worst case, I think that c99 clog can be put into a different
namespace stdc99, and if one wants it, use stdc99::clog. std::clog
then is the one from the C++ standard. Then complex.h can put in a
using for the decl, and presto, the code just works.
> Date: Mon, 19 Jun 2000 09:15:28 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> There is a related compiler problem: complex is a #define for
> _Complex in C99, provided by <complex.h> was included. That is in
> conflict with <complex>, where complex is a template name. One may
> think this is similar to stdbool.h, which would just not #define
> bool when compiled as C++, but this is different: I don't think
> there is a way to allow both
> double complex x;
> and
> complex<double> y;
> to be used simultaneously.
As a compiler implementor, I can see how to make this work, it's not
that hard. Icky, sure, but doable. The term suitably advanced
parsing techniques comes to mind.
Too bad c99 didn't pick complex_double_t... :-( That would have
allowed a much simpler solution. I suspect the committee will have to
harmonize and rationalize this whole mess somehow. clog(cnum) isn't
better than log(cnum). :-(