Sujet : Re: "A diagram of C23 basic types"
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 03. Apr 2025, 09:15:17
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vslg2l$66fk$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 03.04.2025 09:38, David Brown wrote:
On 03/04/2025 05:43, Janis Papanagnou wrote:
>
In many other languages you have abstractions of numeric types, not
every implicitly encoding variant revealed an the programming level.
That's often fine within a program, but sometimes you need to exchange
data with other programs. In particular, C is the standard language for
common libraries - being able to reliably and consistently exchange data
with other languages and other machines is thus very important.
I consider this an important point! - My background is a bit different,
though; I was working in system environments not restricted to single
languages, single OSes, or systems originating from the same vendor
or even the same country. For data exchange it was important to have
a standard transfer syntax independent of the data types of a specific
programming language. - Don't get me wrong; in the past I've also used
those byte-reverting library functions (for endian'ness), sometimes an
object serialization, but also CORBA, and preferable even ASN.1 (with
an associated transfer syntax). - Being platform/language independent
requires of course an abstraction layer.
This "flexibility" of various sorts of numeric "subtypes", be it in
Fortran, Algol 68, or "C", always appeared odd to me. Things like the
ranged types (say as Pascal or Ada provided) seemed more appropriate
to me for a high-level language.
Janis