int
.But what if I really think that it should be something else? Take, for example, the following code snippet:
void f(unsigned char);
void f(float);
int main() {
f(1);
}
And voila- it's an ambiguous overload. However, logically, I find this to be a bit WTF. I mean, I get it that 1 has type
int
, but the conversion of an integral literal in general into floating-point will be lossy, even if it's not for 1 specifically, whereas the unsigned char
is an exact match for 1. In fact, for literals, it would be more than feasible for the compiler to determine the exactly appropriate type. Here's a very simple rule- if the number is negative, then the type must be signed, else it is unsigned. The type is the smallest integral type which can represent that value exactly. This would cut the need for the long and long-long, unsigned suffixes, and yield more precise type matches in circumstances where it may otherwise be ambiguous. And you know what- if it really matters whether an unsigned char
or an unsigned short
overload is chosen, then I've done it wrong.So now I've had to re-write f above to actually take an int- even though the full range of an int isn't acceptable and I really can only accept 0-255, which will convert an error that the compiler could have detected at run-time into an error that can only be detected at run-time, which I'm certainly not going to write code to detect and will only come up when the GPU starts showing the wrong colours. What even happens if you give Direct3D a range outside of 0-1 normalized float in a given channel anyway?
No comments:
Post a Comment