49 ms·

About int vs sint32, why exactly you should be aware about the differences? The only cases when I encounter these differences, they look like broken C++ compile

About int vs sint32, why exactly you should be aware about the differences? The only cases when I encounter these differences, they look like broken C++ compiler: https://stackoverflow.com/q/50552347/126995 https://stackoverflow.com/q/50552347/126995 Similar about %d and unsigned. Technically UB, practically works fine in 100% of cases. If you ask “but how do you know it works?” I’ll answer “because I read assembly”.

MaxBarraclough 8y ago
> why exactly you should be aware about the differences? Because they aren't assured to be the same. They might happen to be the same on your current platform. C++ isn't like Java. It's the programmer's job to be very aware of these sorts of platform-specific points of variation. I don't see why you'd deliberately write undefined behaviour when there's no benefit to doing so. This isn't a purely academic concern - I've seen a malformed printf call wreak absolute havoc, presumably because it was stripping too much or too little data off the stack. Was a nightmare to track it down. I don't want to think about which particular families of dangerous type-based mistakes are permissible in my codebase -- I'd rather write code which is correct. > The only cases when I encounter these differences, they look like broken C++ compiler If you write dangerous, non-portable code that invokes UB, you may well find that it works on plenty of real-world platforms. Your code is still wrong. For the specific case of assuming that `int` is 32-bit, you'll probably get away with this sort of clumsiness, yes, but 'ILP64' targets exist, even if they're rare. Additionally, using `int` as a dangerous alias for `int32_t` is not expressive when it comes to readability. > Technically UB, practically works fine in 100% of cases UB can bite you in bizarre, unpredictable, intermittent ways, especially with optimising compilers. Why argue that a bad habit isn't that bad, when you could just avoid doing it? > If you ask “but how do you know it works?” I’ll answer “because I read assembly”. That's a very fragile assurance of correctness. Unless you explicitly embed that assembly code, the compiler is free to generate different code at any point in future. Can you guarantee that you'll never change or upgrade your compiler, tweak its flags, or target another platform? Can you guarantee the optimiser will never change its mind and generate different code for that function?
- Const-me 8y ago
  > They might happen to be the same on your current platform. Good, and I’m not writing STL. I develop user-facing software, and I know the platforms I support. It just happened so that in the last couple of decades, all my current platforms have 32-bit integers, and I don’t expect that to change within my remaining lifetime. > It's the programmer's job to be very aware of these sorts of platform-specific points of variation. Exactly. I’m writing platform-specific code in C++, and I don’t expect compiler to interfere. When I want to abstract these things away I don’t code C++, there’re better languages out there for such requirements. > why you'd deliberately write undefined behaviour when there's no benefit to doing so. Read the comments in the link I’ve posted. Because clang authors share your opinion on the subject, I had to write a couple of pages of boilerplate code, changing ~50 C++ functions for absolutely no value. That’s one of the reasons why I prefer MSVC, by the way. > ILP64 targets exist, even if they're rare. Why should I care? As you see from this example, caring is not free, it has costs. > Additionally, using `int` as a dangerous alias for `int32_t` is not expressive when it comes to readability. Additionally, typing int is 3 keypresses, typing int32_t is 8. Given how much code I type every day, and how many integers are there in my code, the difference is not insignificant. Even Nintendo did it better on CodeWarrior toolchain, with u8, u32, u64, etc. > UB can bite you in bizarre, unpredictable, intermittent ways, especially with optimising compilers. I think you’re demonizing UB. Different cases are different. Some will crash your app right away, the worst of them will silently give incorrect results with 0.001% probability, but the code from my original comment is harmless. Also C++ compilers aren’t perfect, couple times in my career I found bugs in them. Many times, I found bugs in standard libraries or OSes. If you think writing 100% standard compliant C++ code guarantees correct programs, I have bad news for you. > Can you guarantee that you'll never change or upgrade your compiler, tweak its flags Do you have an example of specific compiler version, or flags, that will break my code above, when targeting i386, amd64 or arm32 platforms?

MaxBarraclough 8y ago

> why exactly you should be aware about the differences? Because they aren't assured to be the same. They might happen to be the same on your current platform. C++ isn't like Java. It's the programmer's job to be very aware of these sorts of platform-specific points of variation. I don't see why you'd deliberately write undefined behaviour when there's no benefit to doing so. This isn't a purely academic concern - I've seen a malformed printf call wreak absolute havoc, presumably because it was stripping too much or too little data off the stack. Was a nightmare to track it down. I don't want to think about which particular families of dangerous type-based mistakes are permissible in my codebase -- I'd rather write code which is correct. > The only cases when I encounter these differences, they look like broken C++ compiler If you write dangerous, non-portable code that invokes UB, you may well find that it works on plenty of real-world platforms. Your code is still wrong. For the specific case of assuming that `int` is 32-bit, you'll probably get away with this sort of clumsiness, yes, but 'ILP64' targets exist, even if they're rare. Additionally, using `int` as a dangerous alias for `int32_t` is not expressive when it comes to readability. > Technically UB, practically works fine in 100% of cases UB can bite you in bizarre, unpredictable, intermittent ways, especially with optimising compilers. Why argue that a bad habit isn't that bad, when you could just avoid doing it? > If you ask “but how do you know it works?” I’ll answer “because I read assembly”. That's a very fragile assurance of correctness. Unless you explicitly embed that assembly code, the compiler is free to generate different code at any point in future. Can you guarantee that you'll never change or upgrade your compiler, tweak its flags, or target another platform? Can you guarantee the optimiser will never change its mind and generate different code for that function?

Const-me 8y ago
> They might happen to be the same on your current platform. Good, and I’m not writing STL. I develop user-facing software, and I know the platforms I support. It just happened so that in the last couple of decades, all my current platforms have 32-bit integers, and I don’t expect that to change within my remaining lifetime. > It's the programmer's job to be very aware of these sorts of platform-specific points of variation. Exactly. I’m writing platform-specific code in C++, and I don’t expect compiler to interfere. When I want to abstract these things away I don’t code C++, there’re better languages out there for such requirements. > why you'd deliberately write undefined behaviour when there's no benefit to doing so. Read the comments in the link I’ve posted. Because clang authors share your opinion on the subject, I had to write a couple of pages of boilerplate code, changing ~50 C++ functions for absolutely no value. That’s one of the reasons why I prefer MSVC, by the way. > ILP64 targets exist, even if they're rare. Why should I care? As you see from this example, caring is not free, it has costs. > Additionally, using `int` as a dangerous alias for `int32_t` is not expressive when it comes to readability. Additionally, typing int is 3 keypresses, typing int32_t is 8. Given how much code I type every day, and how many integers are there in my code, the difference is not insignificant. Even Nintendo did it better on CodeWarrior toolchain, with u8, u32, u64, etc. > UB can bite you in bizarre, unpredictable, intermittent ways, especially with optimising compilers. I think you’re demonizing UB. Different cases are different. Some will crash your app right away, the worst of them will silently give incorrect results with 0.001% probability, but the code from my original comment is harmless. Also C++ compilers aren’t perfect, couple times in my career I found bugs in them. Many times, I found bugs in standard libraries or OSes. If you think writing 100% standard compliant C++ code guarantees correct programs, I have bad news for you. > Can you guarantee that you'll never change or upgrade your compiler, tweak its flags Do you have an example of specific compiler version, or flags, that will break my code above, when targeting i386, amd64 or arm32 platforms?