0

Having such a simple C++ code:

//...
DWORD time1 = 12;
DWORD time2 = 1;
DWORD timeDelta = time2 - time1;

if (timeDelta == -11) {
    swprintf_s(g_msgbuf, L"equality 1\n");
    OutputDebugString(g_msgbuf);
}


if (timeDelta == 4294967285) {
    swprintf_s(g_msgbuf, L"equality 2\n");
    OutputDebugString(g_msgbuf);
}
//...

I'm getting BOTH outputs(both conditions fulfilled):

equality 1

equality 2

I know that timeDelta variable when treated as signed 'll be -11 and as unsigned as 4294967285 BUT i'ts so strange to me. Such an ambiguity may lead to serious problems in the code later. Since the timeDelta variable is of type DWORD which means unsigned long should't the == operator take it into consideration and then fulfilled ONLY in the second case (if (timeDelta == 4294967285)...)!?

In my opinion it SHOULD be absolutely NECESSARILY to EXLPICITELLY use the type casting like: if ((singed long)timeDelta == -11)... to make the condition fulfilled!?

darro911
  • 136
  • 6
  • If it is critical in your code, use your own types and comparison operators, C++ gives you the possibility to do so without losing performance. – Sebastian Jun 05 '22 at 10:44
  • 1
    Does this answer your question? [How do I avoid implicit conversions on non-constructing functions?](https://stackoverflow.com/q/12877546/11683) – GSerg Jun 05 '22 at 10:51
  • 2
    You need a better title. The title of the question should summarize the essence of the question, like so: [How to prevent implicit conversion from int to unsigned int?](https://stackoverflow.com/questions/36162068/how-to-prevent-implicit-conversion-from-int-to-unsigned-int) – rustyx Jun 05 '22 at 11:01
  • @darro911 What do you expect to happen instead? Compiler error or false comparison? Anyway there's a long history of this kind of comparison working and it's not going to change now. – john Jun 05 '22 at 11:02
  • @darro - `(singed long)timeDelta` isn't going to work either, if the value is larger than the maximum signed value. The choice of which value to promote was done in the 1970's, so it is **way** too late to change that now. Instead just avoid mixing signed and unsigned values, whenever possible. – BoP Jun 05 '22 at 11:05
  • @Clifford It's NOT only my opinion, i'm NOT alone with this statement. There are MANY people who also presents my point of view in the topic. Ans the fact that the language definition was made decades ago absolutely doesn't mean the decision was right!!! –  darro911 Jun 05 '22 at 17:34
  • @darro911 That is why compilers have the option to make this a warning or an error. For backwards compatibility reason it won't be changed for all code. – Sebastian Jun 05 '22 at 17:37
  • @Sebastian Ok I know that this CAN be done with compiler options BUT such implicit conversion should ONLY be able to do when done EXPLICITELY when the programmer is 100% aware what he/she is doing! Nothing should be done behind the scene. The backward compatibility is the reason I understated BUT as I said it DOESN'T mean that the language definition made decades ago was right! –  darro911 Jun 05 '22 at 17:49
  • Many leading figures in C++ standardization agree that it was a bad choice then and would have done it differently. – Sebastian Jun 05 '22 at 18:06
  • @Sebastian Yes, right. Can You please tell me if You agree with me that such conversions should only be made on the explicit programmer demand as I said? –  darro911 Jun 05 '22 at 18:27
  • I agree that it would be good, if there were less implicit arithmetic conversions. But even then there would be lots of traps like possible overflow. With an existing language it is difficult to make this absolutely necessary. But the first baby step is done with the introduction of modules. This will reduce the number of libraries, which are included. So there could be different rules locally. – Sebastian Jun 05 '22 at 18:36
  • 1
    Still a matter of opinion. If you want to change it you will have to get yourself a seat in the ISO committee. C++ is a systems level language, and as such much of how it works is closely related to how the hardware works - for good reason. If you wish it were a different language, the solution is simple - use a different language. However you have missed my point- all compilers support exactly the kind of type agreement enforcement you desire, si it is kind of a non problem. – Clifford Jun 05 '22 at 20:38

0 Answers0