On 2019-10-15 19:12, Tony V E via Std-Proposals wrote:
>
> Yes, obviously there are cases where format matters. They tend to be
> when communicating to other devices/computers.
> I need to give the correct format to my projectors. But that's 1% of my
> code, not 99%.
But you do care about precision of your internal calculations, don't
you? You probably also care about denormals and special values? You
probably assume that double is binary64, but that is not guaranteed by
the standard, is it? So, your assumption is unfounded, even if it holds
true in your particular environment.
The same thing is with integers. The standard doesn't say much about
int, so you can't be confident about which integer values are
representable by int and which are not. This is especially sad, given
that signed overflow is UB. So, basically anything beyond a toy project
should use intN_t in order to have behavior that can be reasoned about,
especially in corner cases.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
What I've found over and over again in the past is that code that used fixed-sizes was later upgraded to "default" sizes, or upgraded to the next size up.
ie code that used int16 later used int32 or just int. (Unless it was writing to a file format, etc)
Often people think "I know this is N bits, I should 'lock it in' to be N bits forever, so that behaviour doesn't change". But circumstances change. You run on a bigger machine, it uses bigger numbers (ie more elements in a vector). You run on a smaller machine, you tackle smaller problems with smaller numbers. But the original idea was that int would scale (someone broke that when it didn't move to 64bits unfortunately).
I can see cases for int_least_N, saying "it won't work otherwise". But lots of code can generically scale to machine size.
Maybe times have changed. Maybe we will never upgrade to 128bit pointers/ints/floats. But I went through both the 16 -> 32 and the 32 -> 64 transitions, and I had to fix much much more fixed-sized code than default-sized code.
Although maybe that experience is no longer valid, and is just tainting my judgement.
--