compiler unable to choose proper overloaded function (causes C2666)

Discussion in 'C++' started by Jason Doucette, Jul 26, 2007.

  1. If you have two overloaded functions:

    double maximum(double a, double b, double c);
    int maximum(int a, int b, int c);

    They work fine if you call maximum() with all arguments as doubles, or
    all as ints. But, if you mix up doubles with ints in the argument
    list, it doesn't know which maximum() to call... but only one could
    possibly match -- the one that takes doubles.

    I assume this is not a bug, and is by definition... but, why?

    Jason
     
    Jason Doucette, Jul 26, 2007
    #1
    1. Advertising

  2. Jason Doucette wrote:
    > If you have two overloaded functions:
    >
    > double maximum(double a, double b, double c);
    > int maximum(int a, int b, int c);
    >
    > They work fine if you call maximum() with all arguments as doubles, or
    > all as ints. But, if you mix up doubles with ints in the argument
    > list, it doesn't know which maximum() to call... but only one could
    > possibly match -- the one that takes doubles.
    >
    > I assume this is not a bug, and is by definition... but, why?


    Floating-integral conversions (from a double to an int) and floating
    point conversions (from an int to a double) have the same rank as far
    as overload resolution is concerned.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jul 26, 2007
    #2
    1. Advertising

  3. > Floating-integral conversions (from a double to an int) and floating
    > point conversions (from an int to a double) have the same rank as far
    > as overload resolution is concerned.


    Ok. I didn't think that implicit conversions from a double to an int
    were *ever* allowed, since they can lose information.

    Jason
     
    Jason Doucette, Jul 26, 2007
    #3
  4. Jason Doucette wrote:
    >> Floating-integral conversions (from a double to an int) and floating
    >> point conversions (from an int to a double) have the same rank as far
    >> as overload resolution is concerned.

    >
    > Ok. I didn't think that implicit conversions from a double to an int
    > were *ever* allowed, since they can lose information.


    If something potentially dangerous would always be disallowed, we'd not
    have many feature of the language. Just imagine dereferencing a pointer
    not allowed because (Oh, no!) the pointer can be invalid!

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jul 26, 2007
    #4
  5. Jason Doucette wrote:

    >> Floating-integral conversions (from a double to an int) and floating
    >> point conversions (from an int to a double) have the same rank as far
    >> as overload resolution is concerned.

    >
    > Ok. I didn't think that implicit conversions from a double to an int
    > were *ever* allowed, since they can lose information.


    It's worse than that. The conversion from double to int discards the
    fractional part, but if the resulting integer is outside the bounds of int,
    it's undefined behaviour.

    --
    rbh
     
    Robert Bauck Hamar, Jul 27, 2007
    #5
  6. Robert Bauck Hamar wrote:
    > Jason Doucette wrote:
    >
    >>> Floating-integral conversions (from a double to an int) and floating
    >>> point conversions (from an int to a double) have the same rank as
    >>> far as overload resolution is concerned.

    >>
    >> Ok. I didn't think that implicit conversions from a double to an int
    >> were *ever* allowed, since they can lose information.

    >
    > It's worse than that. The conversion from double to int discards the
    > fractional part, but if the resulting integer is outside the bounds
    > of int, it's undefined behaviour.


    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jul 27, 2007
    #6
  7. Robert Bauck Hamar wrote:
    > Jason Doucette wrote:
    >
    >>> Floating-integral conversions (from a double to an int) and floating
    >>> point conversions (from an int to a double) have the same rank as
    >>> far as overload resolution is concerned.

    >>
    >> Ok. I didn't think that implicit conversions from a double to an int
    >> were *ever* allowed, since they can lose information.

    >
    > It's worse than that. The conversion from double to int discards the
    > fractional part, but if the resulting integer is outside the bounds
    > of int, it's undefined behaviour.


    I am not sure in what sense it's a loss of information, actually. The
    conversion is well-defined, it discards the fractional part and retains
    the integral part, in the same fashion as when you divide two integers
    the result is [essentially] rounded to the next integer toward zero.
    Is that a loss of information? <shrug>

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jul 27, 2007
    #7
  8. Jason Doucette

    James Kanze Guest

    On Jul 27, 12:04 am, Jason Doucette <> wrote:
    > > Floating-integral conversions (from a double to an int) and floating
    > > point conversions (from an int to a double) have the same rank as far
    > > as overload resolution is concerned.


    > Ok. I didn't think that implicit conversions from a double to an int
    > were *ever* allowed, since they can lose information.


    It's a serious bug in the standard. There have been several
    proposals to "deprecate" such implicit conversions (one by
    Stroustrup himself, I think), but for whatever reasons, they
    never got anywhere.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jul 27, 2007
    #8
  9. > > Ok. I didn't think that implicit conversions from a double to an int
    > > were *ever* allowed, since they can lose information.

    >
    > If something potentially dangerous would always be disallowed, we'd not
    > have many feature of the language. Just imagine dereferencing a pointer
    > not allowed because (Oh, no!) the pointer can be invalid!


    Your example is on a totally different level.

    Everyone knows almost every floating point value converted to an
    integer results in a significant loss of information. Most languages
    disallow this implicit casting from floating point to integer. I
    would assume C / C++ did this also. In fact, it does -- you cannot
    assign a floating point value to an integer.

    So, it's intuitive to think that this would not be considered within
    the overload resolution... I am still dumbfounded as to why it does.

    Jason
     
    Jason Doucette, Jul 27, 2007
    #9
  10. > It's worse than that. The conversion from double to int discards the
    > fractional part, but if the resulting integer is outside the bounds of int,
    > it's undefined behaviour.


    Are you positive about that? I thought it set it to the maximum /
    minimum integer value... In my programs, if there's a case a floating
    point will be out of integer range, I check before the cast, just in
    case. I don't think I've ever tested what would happen if I didn't...

    Jason
     
    Jason Doucette, Jul 27, 2007
    #10
  11. > I am not sure in what sense it's a loss of information, actually.

    You can't be serious? If I convert a floating point value of pi to an
    integer, and get 3, then I've lost the fractional part -- that's the
    information that's lost. I don't think anyone would disagree that
    information has been lost. It's no different from converting a 32-bit
    integer to a byte, you may lose information, since the upper 24-bits
    may have had 1's in them that are now no longer stored. That's a lose
    of information.


    > The
    > conversion is well-defined, it discards the fractional part and retains
    > the integral part, in the same fashion as when you divide two integers
    > the result is [essentially] rounded to the next integer toward zero.


    The conversion is well defined. That doesn't imply information is not
    lost.


    > Is that a loss of information? <shrug>


    Yes, of course, it is.

    Jason
     
    Jason Doucette, Jul 27, 2007
    #11
  12. > It's a serious bug in the standard.

    Agreed.


    > There have been several
    > proposals to "deprecate" such implicit conversions (one by
    > Stroustrup himself, I think), but for whatever reasons, they
    > never got anywhere.


    Wow.

    Jason
     
    Jason Doucette, Jul 27, 2007
    #12
  13. Jason Doucette wrote:

    >> It's worse than that. The conversion from double to int discards the
    >> fractional part, but if the resulting integer is outside the bounds of
    >> int, it's undefined behaviour.

    >
    > Are you positive about that? I thought it set it to the maximum /
    > minimum integer value... In my programs, if there's a case a floating
    > point will be out of integer range, I check before the cast, just in
    > case. I don't think I've ever tested what would happen if I didn't...


    The quote from the standard (§4.8):
    An rvalue of a floating point type can be converted to an rvalue of an
    integer type. The conversion truncates; that is, the fractional part is
    discarded. The behaviour is undefined if the truncated value cannot be
    represented in the destination type.

    --
    rbh
     
    Robert Bauck Hamar, Jul 27, 2007
    #13
  14. Jason Doucette wrote:
    >> I am not sure in what sense it's a loss of information, actually.

    >
    > You can't be serious? If I convert a floating point value of pi to an
    > integer, and get 3, then I've lost the fractional part


    I think you confuse the word "lost" with the word "discarded". The
    former implies the unwanted result due to having no control over the
    outcome of some events.

    I believe most of the complaints about the language "inadequacies" stem
    from the inability of some people to take responsibility to learn and
    consciously use (or not use) certain features.

    > -- that's the
    > information that's lost. I don't think anyone would disagree that
    > information has been lost.


    *I* disagree. So you think wrong.

    > It's no different from converting a 32-bit
    > integer to a byte, you may lose information, since the upper 24-bits
    > may have had 1's in them that are now no longer stored. That's a lose
    > of information.


    No, it's not.

    >> The
    >> conversion is well-defined, it discards the fractional part and
    >> retains the integral part, in the same fashion as when you divide
    >> two integers the result is [essentially] rounded to the next integer
    >> toward zero.

    >
    > The conversion is well defined. That doesn't imply information is not
    > lost.


    Yes, it does. If you know what the conversion does and you don't want
    to "lose" the information, [read my lips:] do not use the conversion.

    >> Is that a loss of information? <shrug>

    >
    > Yes, of course, it is.


    <shrug> Whatever.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jul 27, 2007
    #14
  15. On Jul 27, 10:49 am, Robert Bauck Hamar <>
    wrote:
    > Jason Doucette wrote:
    > >> It's worse than that. The conversion from double to int discards the
    > >> fractional part, but if the resulting integer is outside the bounds of
    > >> int, it's undefined behaviour.

    >
    > > Are you positive about that? I thought it set it to the maximum /
    > > minimum integer value... In my programs, if there's a case a floating
    > > point will be out of integer range, I check before the cast, just in
    > > case. I don't think I've ever tested what would happen if I didn't...

    >
    > The quote from the standard (§4.8):
    > An rvalue of a floating point type can be converted to an rvalue of an
    > integer type. The conversion truncates; that is, the fractional part is
    > discarded. The behaviour is undefined if the truncated value cannot be
    > represented in the destination type.


    Thanks, Robert! Can't be more clear than that...

    Jason
     
    Jason Doucette, Jul 27, 2007
    #15
  16. > I think you confuse the word "lost" with the word "discarded". The
    > former implies the unwanted result due to having no control over the
    > outcome of some events.


    I think this is being pedantic... what the writers mean by "lost" is
    that the information has disappeared, and you cannot get it back.
    It's unfortunate that programmers don't use proper English, since it
    happens all the time, and most arguments are over definitions and not
    an actual problem...

    (...it is possible to lose something, but still have control over the
    outcome of events, if you're not careful... perhaps that's why they
    use that term? It's hard to say.)


    > I believe most of the complaints about the language "inadequacies" stem
    > from the inability of some people to take responsibility to learn and
    > consciously use (or not use) certain features.


    I generally agree, but sometimes I think it's nice that the language
    protects you as well -- for instance, some languages use the alternate
    slash for integer division (and complains if you use the regular one,
    which is reserved for floating point), which *forces* you to realize
    what you are doing, and that the result will be an integer, and not a
    floating point value... and then you don't get bit. Even I, after
    many years of programming C, have been bitten by integer division,
    since it's not something I use often, and some languages give the
    result as floating point, which I have assumed at times...

    Jason
     
    Jason Doucette, Jul 27, 2007
    #16
    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. BCC
    Replies:
    1
    Views:
    537
    Gianni Mariani
    Jan 9, 2004
  2. Replies:
    5
    Views:
    10,078
  3. krishnakant Mane

    please help me choose a proper gui library.

    krishnakant Mane, Nov 18, 2006, in forum: Python
    Replies:
    2
    Views:
    300
    krishnakant Mane
    Nov 19, 2006
  4. Replies:
    6
    Views:
    341
    werasm
    Nov 2, 2005
  5. Jayden Shui
    Replies:
    5
    Views:
    235
    Juha Nieminen
    Dec 21, 2011
Loading...

Share This Page