The difference between the representation of objects and values ​​on an example

Question

N3797::3.9/4 [basic.types] :

The object representation of an object of type T is a sequence of N unsigned char objects occupied by an object of type T, where N is equal to SizeOf (T). Representation of the value of an object is a set of bits that store a value of type T. For trivially copied types, the value of Representation is a set of bits in the representation of an object that defines a value that is one discrete element, an implementation-defined set of values

N3797::3.9.1 [basic.fundamental] says:

For narrow character types, all bits of the object representation participate in the representation of values.

Consider the following structure:

 struct A { char a; int b; } 

I think that for A not all bits of the representation of the object participate in the representation of values ​​due to the addition added by the implementation. But what about other foundational types? The Standard says: N3797::3.9.1 [basic.fundamental]

For narrow character types, all bits of the object representation participate in the value representation. These requirements are not suitable for other types.

I cannot imagine why this is not true for say int or long . What reason? Could you clarify?

Answer 1

An example is Unisys mainframes, where int has 48 bits, but only 40 are represented in the value representation (and INT_MAX is 2 ^ 39-1); others should be 0. I assume that any machine with an architecture tag will have similar problems.

EDIT:

Just some additional information: Unisys mainframes are probably the only remaining architectures that are truly exotic: Unisys Libra (ex-Burroughs) have a 48-bit word, use signed values ​​for integers and have a tagged architecture where the data itself contains information about its type . Unisys Dorado is ex-Univac: 36 bits of one padding (but no reserved bits for tags) and 9 bits of char.

From what I understand, however, Unisys terminates them (or shook them last year) in favor of the Intel system. As soon as they disappear, almost all systems will be 2, 32 or 64 bits, and all but the mainframe IBM will use the IEEE floating field (and IBM is moving or moving in that direction as well). Thus, there is no motivation for the standard to continue with special wording to support them; after all, after a couple of years in lesat, C / C ++, maybe follow the Java path and overlay the view with all its basic data types.

Answer 2

This is probably intended to provide a compiler margin for optimization on some platforms.

Consider, for example, a 64-bit platform in which processing non-64-bit values ​​carries a large fine, then it would be reasonable to have, for example, short use only 16 bits (rep value), but still use 64-bit storage (obj repr).

This rationale applies to the fastest targets with the minimum width specified by <stdint> . Sometimes larger types are not slower, but faster to use.

Answer 3

As far as I understand, at least one case for this deals with traps, usually on exotic architectures. This issue is addressed in N2631: Resolution of the difference between C and C ++ regarding the representation of integer objects . This is a very long time, but I will give a few sections (the author is James Kanze, so if we are lucky, he may come in and continue to comment) that says (my emphasis).

In recent discussions in comp.lang.C ++, it has become clear that C and C ++ have different requirements regarding the object representation of integers and that at least one real C implementation does not match C ++. The purpose of this article is to offer wording for aligning a C ++ standard with C.

It should be noted that the problem concerns only fairly "exotic" equipment. In this regard, a slightly more complex problem arises.

and

If C compatibility is required, it seems to me that the easiest and most reliable way to achieve this is to include the exact words from the C standard instead of the current wording. Therefore, I propose to adopt the wording from standard C, as shown below.

and

Certain representations of objects do not have to represent an object type value. If the stored value of an object has this representation and is read by an lvalue expression that does not have a character type, the behavior is undefined. If such a representation is created by a side effect that changes all or any part of an object using an lvalue expression that does not have a character type, the behavior is undefined. Such a representation is called a trap representation.

and

For signed integer types [...] Which one is used is determined by the implementation, as well as the value with the sign bit 1 and all bits of the values ​​0 (for the first two) or with the sign bit and all bits of the values ​​1 (for one addition) represent a trap representation or a normal value . In the case of a sign, a quantity, and one complement, if this representation is a normal value, it is called a negative zero.