468,780 Members | 2,318 Online

# why is abs function complaining about double?

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);
Thanks,
Daniel

Jul 23 '05 #1
6 14895
If you use stdlib.h abs(): taht has a int as argument, for a double you
use fabs()

Jul 23 '05 #2
sa************@hotmail.com wrote:
using g++ in cygwin...

sv.cpp:13: warning: passing `double' for converting 1 of `int abs(int)'

extract...

#include <stdlib.h> <cstdlib> would be better. #include <Math.h> <cmath> would be better. (and there it's math.h, not Math.h in any case).
double pythag(double a, double b)
{
double absa, absb, tmp;

absa = abs(a); // this is line 13, where is the int?
In the signature for abs(), of course! IF your argument is a double, you
want std::fabs().
absb = abs(b);

Similarly.

HTH,
--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays
Jul 23 '05 #3
<sa************@hotmail.com> wrote in message
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. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 23 '05 #4
P.J. Plauger wrote:
<sa************@hotmail.com> wrote in message
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]

Could you expand on this a little bit? Is it that abs() is supposed to
be overloaded to take/return doubles? (And wouldn't <cmath> need to be
included to get that behavior in any case?)

Many thanks,
--ag

--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays
Jul 23 '05 #5
"Artie Gold" <ar*******@austin.rr.com> wrote in message
news:3i************@individual.net...
P.J. Plauger wrote:
<sa************@hotmail.com> wrote in message
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
Yes, and quite a few other types:

(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.
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

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
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

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

HTH,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 23 '05 #6
Wow, C/C++ has become so complicated, perhaps I might be better off
with a newer language. But I don't like java or C#.NET. What is a
good standard and compiler to use for cross platform development?
Dinkumware and MsVS? How long does the entry version last? What is
GBin and GSrc?

Jul 23 '05 #7

### This discussion thread is closed

Replies have been disabled for this discussion.