3 ms·
>The slight performance gain on a few systems that you get from using int rather than int16_t int16_t is also unportable as he mentions later >the hugely incr
by snakeanus 11y ago
>The slight performance gain on a few systems that you get from using int rather than int16_t
int16_t is also unportable as he mentions later
>the hugely increased risk of introducing platform-specific undefined behaviour
What risk? Please explain how int introduces undefined behaviour.
>how much performance
It's not about performance. intN_t is NOT guaranteed to exist.
>But you just said in the previous section that it only makes sense to perform pointer arithmetic within a single object anyway.
Yes and that's right.
- lmm 11y ago> int16_t is also unportable as he mentions later It's theoretically unportable. I have yet to see a real system to which it's unportable. > What risk? Please explain how int introduces undefined behaviour. (Signed) integer overflow is undefined behaviour. It is very common to develop on platforms on which int is 32 or 64-bits. This carries a high risk of accidentally overflowing the limits of a 16-bit integer and not realizing. When you do this you don't notice anything (because it doesn't show up on your development machines), but you've introduced undefined behaviour that can easily manifest in practice on machines with 16-bit int.