Re: "A diagram of C23 basic types"

On Sun, 27 Apr 2025 12:05:16 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:
 

On Wed, 02 Apr 2025 16:59:59 +1100
Alexis <flexibeast@gmail.com> wrote:
 

Thought people here might be interested in this image on Jens
Gustedt's blog, which translates section 6.2.5, "Types", of the C23
standard into a graph of inclusions:
>
  https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/
 

>
That's a little disappointing.
IMHO, C23 should have added optional types _Binary32, _Binary64,
_Binary128 and _Binary256 that designate their IEEE-754 namesakes.
Plus, a mandatory requirement that if compiler supports any of
IEEE-754 binary types then they have to be accessible by
above-mentioned names. 

 
I see where you're coming from,

I suppose, you know it because you followed my failed attempt to improve
speed and cross-platform consistency of gcc IEEE binary128 arithmetic.
Granted, in this case absence of common name for the type was much
smaller obstacle than general indifference of gcc maintainers.
So, yes, on the "producer" side the problem of absence of common name
was annoying but could be regarded as minor.

Apart from being a "producer", quite often I am on the other side,
wearing a hat of consumer of extended precision types. When in this
role, I feel that the relative weight of inconsistent type names is
rather significant. I'd guess that it is even more significant for
people whose work, unlike mine, is routinely multi-platform. I would
not be surprised if for many of them it ends up as main reason to
refrain completely from use IEEE binary128 in their software; even when
it causes complications to their work and when the type is
readily available, under different names, on all platforms they care
about.

but I disagree with the suggested
addition;  it simultaneously does too much and not enough.  If
someone wants some capability along these lines, the first step
should be to understand what the underlying need is, and then to
figure out how to accommodate that need.  The addition described
above creates more problems than it solves.

IMHO, a need for a common name for IEEE binary128 exists for quite some
time. For IEEE binary256 the real need didn't emerge yet. But it will
emerge in the hopefully near future.