Could it be that sizeof (T *)! = Sizeof (const T *)?

Question

I argue with my boss about this. They say, "Yes, they can be different."

Is it possible that sizeof(T*) != sizeof(const T*) for type T ?

Answer 1

No, they cannot be different. For sufficiently different T1 and T2 , sizeof(T1 *) may differ from sizeof(T2 *) , but if T2 is just const T1 , then:

3.9.2 Connection types [basic.compound]

3 [...] Pointers to cv-qualifying and cv-unqualified versions (3.9.3) of types compatible with layouts should have the same requirements for the representation and alignment of values ​​(3.11). [...]

And any type T compatible with layouts with itself:

3.9 Types [basic.types]

11 If two types T1 and T2 are the same type, then T1 and T2 are layout compatible types. [...]

---

The representation of a value refers to the representation of an object; you cannot have the same representation of a value without having the same representation of an object. The latter means that the same number of bits is required.

3.9 Types [basic.types]

4 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) . A representation of an object value is a collection of bits that contain a value of type T For trivially copied types, a value representation is a set of bits in an object representation that defines a value that is one discrete element of a particular set of values. ⁴⁴

44). The C ++ memory model is assumed to be compatible with the ISO / IEC 9899 programming language model.

The point of demand, the reason is that it does not just say that the two types have the same representation of the object, is that T * and const T * have not only the same number of bits, but also the same bits in T * and const T * , which make up the value. This should guarantee not only that sizeof(T *) == sizeof(const T *) , but it means that you can use memcpy to copy the value of the T * pointer to the value of the const T * pointer or vice versa and get a meaningful result, the same the result will be obtained using const_cast .

Alignment requirements also provide some additional guarantees, but they are difficult to explain properly and are not directly related to this issue, and there are problems in the standard that undermine some of the implied guarantees, so I think it’s best to ignore it.

Answer 2

Microchip released such a C compiler, where sizeof(T*) was 2, but sizeof(const T*) was 3.

The C compiler was not compatible with the standards in several ways, so it doesn’t say anything about what it really is (I suspect it is not, and the other answers agree).

Answer 3

Hmm, this is very esoteric, but I think that in theory there could be an architecture that has, say, 256 bytes of RAM at address 0 and, say, a few kilobytes of ROM at higher addresses. And there may be a compiler that would create an 8-bit pointer for int *i , because 8 bits is enough to hold the address of any object in a very limited area of ​​RAM, and any changed object, of course, is implicitly known as the area in RAM. Pointers of type const int *i would need 16 bits so that they could point to any place in the address space. The 8-bit pointer int *i can be assigned to the 16-bit pointer const int *i (but not vice versa), so that the flexibility requirement of the C standard will be satisfied.

But if such an architecture exists, I would really like to see it (but not write code for it) :)

Answer 4

As for standard C ++, they cannot be different. C and C ++ are similar to this point.

But there are many architectures where compilers are written that do not follow this rule. In fact, we are not really talking about standard C ++, and some people claim that the language is not C ++, but my reading of your question (before adding the language advocate tag) is more related to the possibility.

In this case, it is possible. You may well find that the pointer to ROM (therefore const) is different from the pointer to RAM (const or non const.)

If you know for sure that your code will only work on a standard compiler, your guess is correct. If not, then I would carefully think about their sizes being the same.