"Artie Gold" <ar*******@austin.rr.com> wrote in message
news:3i************@individual.net...
P.J. Plauger wrote: <sa************@hotmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
using g++ in cygwin...
sv.cpp:13: warning: passing `double' for converting 1 of `int abs(int)'
extract...
#include <stdlib.h>
#include <Math.h>
double pythag(double a, double b)
{
double absa, absb, tmp;
absa = abs(a); // this is line 13, where is the int?
absb = abs(b);
g++ under cygwin doesn't fully conform to the C++ Standard,
a problem with many implementations in this area. The C++
Standard requires a number of extensions to the C library,
which the C library maintainers often choose not to do and
the C++ library maintainers don't have permission to do.
Dinkumware supplies both libraries, so this program works
fine with our C/C++ library.
P.J.: [I hope the salutation is appropriate]
Work fine, thanks.
Could you expand on this a little bit? Is it that abs() is supposed to be
overloaded to take/return doubles?
Yes, and quite a few other types:
-- <math.h> adds overloads for float, double, and long double
-- <stdlib.h> adds an overload for long
-- <complex> adds overloads for all complex<T>
-- <valarray> adds overloads for all valarray<T>
(And wouldn't <cmath> need to be
included to get that behavior in any case?)
Nope. The C++ Standard effectively says:
1) The Standard C headers <xxx.h> are no longer fundamental.
Instead, the new Standard C++ headers <cxxx> define all the
old C stuff, plus a mess of overloads for abs and other
functions, in namespace std.
2) The revised <xxx.h> headers simply include their
corresponding <cxxx> versions, then hoist all the defined
names into the global namespace with using declarations.
Thus, including <math.h> should define abs(float),
abs(double), and abs(long double). You can pull this
off without performing the full inversion I describe
above, but it still requires substantial changes to
the C header files.
C compilers have been around for upwards of 35 years now.
Well over 100 different C libraries have evolved over
that period, each accumulating its own history of
proprietary extensions used by a large and growing
base of system and user code. These days, it is not
uncommon for the C library to be maintained by a group
that is quite independent of the C++ maintainers, a
group with a different development schedule and many
more constituencies than just C++ programmers.
The C++ people inside a large enterprise can usually
get chunks of code added to existing C headers,
preferably inside #ifdef __cpluplus/#endif wrappers.
But they have no chance, politically or technically,
of completely usurping the fundamental role of the
C development environment. Third-party C++ library
suppliers have it even worse -- they can make *no*
changes to existing C headers, and they have little
chance of completely replacing those headers and
replicating all the idiosyncracies of each system.
The C++ library that comes with gcc is effectively
a third-party library, since it sits atop several
different C libraries each maintained by other groups.
STLport, SGI/STL and the other bolt-on C++ libraries
suffer the same problem. The glibc folk, who provide
the Linux library, have been openly antagonistic to
C++. So you will find few of the extensions to C
mandated by the C++ Standard where they're needed
inside the <xxx.h> headers.
The nonstandard trick is to put the extensions just
inside the <cxxx> headers. Programmers who make a
point of using the <cxxx> headers are content, but
people like the OP in this thread get brought up
short.
Dinkumware is in a different position from other
third-party vendors:
1) We have a number of OEM customers, Microsoft the
most widely used among them, who ship our C++ library
atop their existing C library. Either we modify their
C library headers as needed for them, or we show them
what to pick up from our C headers, to provide much
better conformance. (There are still minor issues about
namespaces, but that's a whole 'nother topic.)
2) We have other OEM customers who ship both our C
and C++ libraries. They can fully conform, if they
choose. (Why they might choose not to fully conform
is yet another topic.)
3) We license our libraries directly to end users.
They can configure our C++ library to work "native"
atop an existing C library or with our C library
included in the package. The native configuration
is less conforming, but mixes better with older code.
By using our C library, you can be completely
conforming and better support applications intended
to be portable.
There have been many discussions of the limited support
for "export". Seven years after formal approval of the
C++ Standard, only compilers that use the Edison
Design Group front end (and the Dinkumware libraries)
have a chance at 100 per cent conformance. But the
C library changes required by the C++ Standard cause
much wider conformance problems. They're just less
sexy than template issues, I suppose.
Both conformance shortfalls have occurred because the
C++ committee insisted on overreaching, despite plenty
of warnings. I only hope that the next revision of the
C++ Standard fixes some of these problems and doesn't
add new ones.
HTH,
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com 
