Subject: Re: [std-proposals] Reserve good keywords for floating point types
From: Tony V E (tvaneerd_at_[hidden])
Date: 2019-10-15 17:16:37
On Tue, Oct 15, 2019 at 12:34 PM Andrey Semashev via Std-Proposals <
> 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
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
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
Although maybe that experience is no longer valid, and is just tainting my
-- Be seeing you, Tony
STD-PROPOSALS list run by firstname.lastname@example.org
Standard Proposals Archives on Google Groups