compiler unable to choose proper overloaded function (causes C2666)

[Jason Doucette]

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

[Victor Bazarov]

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

[Jason Doucette]

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

[Victor Bazarov]

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

[Robert Bauck Hamar]

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

[Victor Bazarov]

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]

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

[James Kanze]

On Jul 27, 12:04 am, Jason Doucette <[e-mail]:

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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jason Doucette]

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]

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]

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]

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

[Robert Bauck Hamar]

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

[Victor Bazarov]

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.

<shrugWhatever.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jason Doucette]

On Jul 27, 10:49 am, Robert Bauck Hamar <[e-mail]>
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]

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