On Aug 12, 8:39 pm, Al Grant <algr...@myrealbox.com> wrote:
> 26.5 adds overloads for some of the C functions, e.g.
> single-precision math.  It is clear that <cstdlib> and
> <cmath> must have these overloads.  But do <stdlib.h>
> and <math.h> also have the overloads?

In my opinion YES.   There is necessarily C++ stuff in
the whatever your C++ implementation is for math.h.
Whether this means that it has a different file than your
C implmentation or there are some #if's in there to turn
off the C++ when the C compiler is using it, is left
up to the implmentors.

>  But if you include <math.h> in C++, are
> you getting "the Standard C header"?   D.5#2 would
> seem to suggest that no, <math.h> is a header which
> takes <cmath> and adds using-declarations.

You are correct.  The C++ math.h is defined in terms
of <cmath> which is defined to have the same stuff as
the C math.h plus the overloads (and the fact that the
non-macro globals are defined in the std namespace).

> Implementations differ in whether math.h has the
> overloads, yet this is an important point to standardize
> given it either results or doesn't result in a silent behavior
> change when compiling C as C++.

You're in trouble anyhow.   You can't compile C as C++
without addressing all sorts of issues.   C++ is not upwardly
compatible to C.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Ron <ron.natalie@gmail.com> writes:
> On Aug 12, 8:39 pm, Al Grant <algr...@myrealbox.com> wrote:
[...]
>> Implementations differ in whether math.h has the
>> overloads, yet this is an important point to standardize
>> given it either results or doesn't result in a silent behavior
>> change when compiling C as C++.
>
> You're in trouble anyhow.   You can't compile C as C++
> without addressing all sorts of issues.   C++ is not upwardly
> compatible to C.

It's certainly not 100% upwardly compatible, but a lot of C code
*can* be compiled as C++ and will have the same meaning if the
author is sufficiently careful.  (A few people -- but only a few --
even have legitimate reasons for doing this.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
   -- Antony Jay and Jonathan Lynn, "Yes Minister"

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Keith Thompson" <kst-u@mib.org> wrote:
>
> It's certainly not 100% upwardly compatible, but a lot of C code
> *can* be compiled as C++ and will have the same meaning if the
> author is sufficiently careful.  (A few people -- but only a few --
> even have legitimate reasons for doing this.)

In at least one case, I know of a C library that explicitly has support for
being compiled as C++. The reason for this is that the library normally uses
longjmp to unwind the stack, because that is the best that C can offer. That
is not ideal, and happens to interact fairly poorly with some C++ exception
implementations. This makes the library compiled as C not very suitible for
using with C++ programs.

When compiling as C++ it is able to use the exception mechanism, which is a
cleaner way to handle the stack unwinding, and can be used safely, without
leaking memory.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

26.5 adds overloads for some of the C functions, e.g.
single-precision math.  It is clear that <cstdlib> and
<cmath> must have these overloads.  But do <stdlib.h>
and <math.h> also have the overloads?

26.5#2 suggests that the overloads are a difference
between e.g. <cmath> and "the Standard C header"
<math.h>.  But if you include <math.h> in C++, are
you getting "the Standard C header"?  D.5#2 would
seem to suggest that no, <math.h> is a header which
takes <cmath> and adds using-declarations.  D.5#3
reinforces this: it says "<cstdlib> provides... <stdlib.h>
makes these available, much as in the C standard" -
where "much as" might suggest "apart from differences
such as overloads that have already been mentioned
in this Standard".  If <stdlib.h> was to have precisely
its Standard C implementation it would have been easy
to say that (and that would imply no overloads).

Implementations differ in whether math.h has the
overloads, yet this is an important point to standardize
given it either results or doesn't result in a silent behavior
change when compiling C as C++.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]