why is abs function complaining about double?

Discussion in 'C++' started by sandwich_eater@hotmail.com, Jul 2, 2005.

  1. Guest

    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 2, 2005
    #1
    1. Advertising

  2. Guest

    If you use stdlib.h abs(): taht has a int as argument, for a double you
    use fabs()
     
    , Jul 2, 2005
    #2
    1. Advertising

  3. Artie Gold Guest

    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
     
    Artie Gold, Jul 2, 2005
    #3
  4. P.J. Plauger Guest

    <> wrote in message
    news:...

    > 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
     
    P.J. Plauger, Jul 3, 2005
    #4
  5. Artie Gold Guest

    P.J. Plauger wrote:
    > <> wrote in message
    > news:...
    >
    >> 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
     
    Artie Gold, Jul 3, 2005
    #5
  6. P.J. Plauger Guest

    "Artie Gold" <> wrote in message
    news:...

    > P.J. Plauger wrote:
    >> <> wrote in message
    >> news:...
    >>
    >>> 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
     
    P.J. Plauger, Jul 3, 2005
    #6
  7. Guest

    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 3, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sydex
    Replies:
    12
    Views:
    6,500
    Victor Bazarov
    Feb 17, 2005
  2. =?ISO-8859-15?Q?Daniel_Sch=FCle?=

    why no arg, abs methods for comlex type?

    =?ISO-8859-15?Q?Daniel_Sch=FCle?=, Aug 5, 2005, in forum: Python
    Replies:
    18
    Views:
    505
    Bengt Richter
    Aug 6, 2005
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,948
    Smokey Grindel
    Dec 2, 2006
  4. Klaas Vantournhout

    f2c's abs conflicts with <complex> abs

    Klaas Vantournhout, Oct 31, 2006, in forum: C++
    Replies:
    3
    Views:
    388
    Victor Bazarov
    Oct 31, 2006
  5. markscottwright
    Replies:
    7
    Views:
    386
    James Kanze
    Aug 3, 2007
Loading...

Share This Page