I am reading this post which is related to char and byte, and come across the following words:
An
int*could still be implemented as a single hardware pointer, since C++ allowssizeof(char*) != sizeof(int*).
How to understand 'C++ allows sizeof(char*) != sizeof(int*)'?
There are (or were) machines which could only address entire "words", where a word was large enough to hold several characters. For example, the PDP-6/10 had a word-size of 36-bits. On such a machine, you might implement 9-bit bytes and represent a byte pointer as the combination of a word pointer and a bit-index within the word. A naïve implementation would require two words for such a pointer, even though a integer pointer would be just a word pointer, occupying a single word.
(The real PDP-6/10 allowed for smaller character sizes -- 6- and 7-bit codings were common, depending on use case -- and since a pointer could not occupy a whole word, it was possible to make a character pointer including bit offset and word address fit inside a single word. But a similar architecture these days would not have the draconian restriction on address space, so that wouldn't work anymore.)
In short, the standard doesn't guarantee it, the result is implementation-defined.
From the standard about sizeof ($5.3.3/1 Sizeof [expr.sizeof])
The sizeof operator yields the number of bytes in the object representation of its operand.
and pointer is compound type ($3.9.2/1.3 Compound types [basic.compound])
pointers to void or objects or functions (including static members of classes) of a given type, 8.3.1;
and ($3.9.2/3 Compound types [basic.compound])
The value representation of pointer types is implementation-defined.
even though ($3.9.2/3 Compound types [basic.compound])
Pointers to layout-compatible types shall have the same value representation and alignment requirements (3.11).
but char and int don't need to have the same value representation. The starndard only says ($3.9.1/2 Fundamental types [basic.fundamental])
There are five standard signed integer types : “signed char”, “short int”, “int”, “long int”, and “long long int”. In this list, each type provides at least as much storage as those preceding it in the list.
and ($3.9.1/3 Fundamental types [basic.fundamental]) etc.
each signed integer type has the same object representation as its corresponding unsigned integer type.
itsnotmyrealname and rici touch on the hardware drivers for this, but I thought it might help to walk through the simplest possible scenario leading to different pointer sizes...
Imagine a CPU that can address 32-bit words of memory, and that the C++ int type is also to be 32 bits wide.
This hypothetical CPU addresses specific words using a numbering: 0 for the first word (bytes 0-3), 1 for the second (bytes 4-7) and so on. int*{0} is therefore your first word in memory (assuming no bizarre nullptr shenanigans require otherwise), int*{1} the second etc..
What should the compiler do to support 8-bit char types? It may have to implement char* support using an int* to identify the word in memory, but still need an extra two bits to store 0, 1, 2 or 3 to say which of the bytes in that word are being pointed to. It would effectively need to generate machine code much as a C++ program might if using...
struct __char_ptr
{
unsigned* p_;
unsigned byte_ : 2;
char get() const { return (*p_ & (0xFF << (8*byte_)) >> 8*byte_; }
void set(char c) { *p_ &= ~(0xFF << (8*byte_)); *p |= c << 8*byte_; }
};
On such a system - sizeof(__char_ptr) > sizeof(int*). The C++ Standard's flexibility allows compliant C++ implementations for (and code portability to/from) weird systems with this or similar issues.
This is also the reason why we can not forward declare enums without providing the underlying size in my answer I provide several references that cover why this is so.
in this comp.lang.c++ discussion: GCC and forward declaration of enum:
[...] While on most architectures it may not be an issue, on some architectures the pointer will have a different size, in case it is a char pointer. [...]
and we can find from this C-Faq entry Seriously, have any actual machines really used nonzero null pointers, or different representations for pointers to different types? it says:
Older, word-addressed Prime machines were also notorious for requiring larger byte pointers (char *'s) than word pointers (int *'s). [...] Some 64-bit Cray machines represent int * in the lower 48 bits of a word; char * additionally uses some of the upper 16 bits to indicate a byte address within a word. [...]
and furthermore:
[...]The Eclipse MV series from Data General has three architecturally supported pointer formats (word, byte, and bit pointers), two of which are used by C compilers: byte pointers for char * and void *, and word pointers for everything else. For historical reasons during the evolution of the 32-bit MV line from the 16-bit Nova line, word pointers and byte pointers had the offset, indirection, and ring protection bits in different places in the word. Passing a mismatched pointer format to a function resulted in protection faults. Eventually, the MV C compiler added many compatibility options to try to deal with code that had pointer type mismatch errors. [...] The old HP 3000 series uses a different addressing scheme for byte addresses than for word addresses; like several of the machines above it therefore uses different representations for char * and void * pointers than for other pointers. [...]
The standard says:
5.3.3 Sizeof
sizeof(char) , sizeof(signed char) and sizeof(unsigned char) are 1 . The result of sizeof applied to any other fundamental type ( 3.9.1 ) is implementation-defined.
Since pointers are "compound types", and the standard makes no mention of byte size consistency between pointers, the compiler writers are free to do as they wish.
