5 ms·
On a different platform, these "friendly" types can be larger, typically 2 or 4 times larger which can be devastating for performance, or smaller, leading to ov
by HelloNurse 7y ago
On a different platform, these "friendly" types can be larger, typically 2 or 4 times larger which can be devastating for performance, or smaller, leading to overflow. They are only "usable" if you restrict yourself on one version, of one compiler, on one hardware platform.
- vips7L 7y agoDoes C++ not have int32_t and the like from C?
- nitwit005 7y agoIt does. I personally stick to those exclusively except for for loop index variables.
- glouwbug 7y agoIt's a good choice. Sometimes your best choice for a general purpose int is typedef Int int32_t; for the entire compilation as a whole, and when things get screwy just bump Int up to int64_t and take the performance hit for the extra bit of safety
- ncmncm 7y ago"i32" is better.
- vips7L 7y agoWhat would be different about loop variables? I don't really write C++.
- rleigh 7y agoI'm assuming here that they would use the `size_type` for the container they are iterating over. Otherwise I'm not sure.
- ncmncm 7y agoAn unsigned type is sometimes a poor choice for a loop index. The compiler then cannot assume the loop will terminate, and generate worse code. Usually this doesn't matter -- until you discover it did.
- rleigh 7y agoGood point. Probably not a problem in practice for most containers, but yet another reason for why the STL (and C library, for that matter) should have used a signed size type from the beginning.
- nitwit005 7y agoYep, it's to match vector/array size_type and difference_type, although I tend to just use size_t and ptrdiff_t directly.
- glouwbug 7y agoYes
- Ives 7y agoYou can still use the Uint32/Uint8/... types. While performance can vary from system to system, the range should be the same on all reasonable platforms.
- Fronzie 7y agoSince C++11 there are types like 'uint_fast32_t', which does allow for platform independent code.