Re: C as a Subset of C++ (or C++ as a superset of C)
Jens Gustedt skrev 2012-08-29 00:07:
Am 28.08.2012 20:38, schrieb Bo Persson:
Jens Gustedt wrote 2012-08-27 18:34:
I am not sure that I understand this one. C has the optional uintXX_t
that are guaranteed to have a fixed width no padding etc, if they
exist. Would it for your purpose just suffice to make some of these
types mandatory e.g for 8, 16, 32 and 64 bit integers?
Why would you want to make this mandatory for everyone? Why not be
satisfied if your code is portable to systems having these types?
No I was asking a question to somebody and not necessarily promoting
that idea. The starting point of that discussion was seeking a way to
be able to access a buffer in "typeless" chunks that correspond to the
common object types that a particular architecture might
have. Seemingly the word "mandatory" provoked some allergic reaction.
Would it be more acceptable for you to have different names for such
beasts (say void8_t, void16_t etc) or would you be ok to mandate
uintXX_t where XX are some multiples of CHAR_BIT?
I don't really care what they are called :-), I just wanted to point out
that any changes to the languages to make them stricter and more
portable, will also affect people who don't intend to make their code
portable at all, because they just cannot anyway.
In another post I mentioned that we use IBM mainframes. The code written
on those depends heavily on the transaction manager of the z/OS (IMS),
and the availability of large DB2 databases. This is mission critical
for many companies.
When we code in "very portable" Java (we do that to, for web services),
we have to add special support hardware to comply with the JVM
specification of its data types. Hardware accelerators for the Java code!
When we code in other languages, it runs natively on the existing
hardware. It is allowed to be big endian, and even use non-IEEE floating
The code we have is not portable anywhere else, not even the Java code,
because it is totally dependent on the surrounding infrastructure.
Having some features "mandatory" for the ease of portability, does
provoke an allergic reaction. Please just let us continue to write our
non-portable code, and write your portable code targeting all other
We are not interested in low level portability, because that is not a
feature we have any use for. It might add extra cost though, if it is
made mandatory like in Java. :-(