指向非工会类的指针的大小可以不同吗? [英] Can size of pointers to non-union classes differ?

问题描述

我了解有些硬件平台需要更多的信息来指向char，而不是指向int(该平台具有不可寻址的字节，因此需要存储指向char的指针指向单词的指针以及单词中字节的索引).因此sizeof(int*) < sizeof(char*)在这样的平台上很有可能.

I understand there are HW platforms where you need more information to point to a char than you need to point to an int (the platform having non-addressable bytes, so a pointer to char needs to store a pointer to a word and also an index of a byte in the word). So it is possible that sizeof(int*) < sizeof(char*) on such platforms.

指向非工会类的指针会发生类似的事情吗? C ++允许在虚函数上使用协变返回类型.假设我们有这样的类:

Can something similar happen with pointers to non-union classes? C++ allows covariant returns types on virtual functions. Let's say we have classes like this:

struct Gadget
{
  // some content
};


struct Widget
{
  virtual Gadget* getGadget();
};

任何接收到Gadget*的调用getGadget()的代码都必须工作，但是当接收到指向类型的指针时，相同的代码(实际上是相同的编译二进制代码)必须工作也可以从Gadget派生(也许是在完全不同的库中定义的).我可以合理地看到发生这种情况的唯一方法是对于所有非工会类类型T和U的sizeof(T*) == sizeof(U*).

Any code which calls getGadget() has to work when receiving a Gadget*, but the same code (actually the same compiled binary code) has to work when it receives a pointer to a type derived from Gadget as well (perhaps one which is defined in a totally different library). The only way I can reasonably see this happening is sizeof(T*) == sizeof(U*) for all non-union class types T and U.

所以我的问题是，假设在一个特定平台上使用一个特定的 practical 编译器(不包括假设的Hell ++)，是否可以合理地期望所有指向非工会类类型的指针都相同尺寸?还是有实用的原因，为什么编译器可能希望使用不同的大小，同时又保持与协变返回类型的兼容性?

So my question is, given one particular practical compiler (that excludes hypothetical Hell++) on one particular platform, is it reasonable to expect that all pointers to non-union class types will be of the same size? Or is there a practical reason why a compiler might want to use different sizes while remaining compliant with covariant return types?

在存在不同级别"的指针的平台上(例如__near和__far)，假定对两个对象都应用了 same 属性.

On platforms where different "levels" of pointer exist (such as __near and __far), assume the same attribute applied to both.

推荐答案

C严格要求所有指向所有结构类型的指针都必须具有相同的表示形式和对齐方式.

C has a hard requirement that all pointers to all structure types have the same representation and alignment.

6.2.5类型

27 [...]所有指向结构类型的指针都必须具有相同的表示和对齐要求. [...]

27 [...] All pointers to structure types shall have the same representation and alignment requirements as each other. [...]

由于标准extern "C"的要求，

C ++有效地要求与C实现二进制兼容，因此间接地，这要求所有指向在C中有效的结构类型的指针(几乎是POD类型)具有相同的表示形式和C ++中的对齐方式.

C++ effectively requires binary compatibility with a C implementation, because of the standard's requirements for extern "C", so indirectly, this requires all pointers to structure types that are valid in C (POD types, pretty much) to have the same representation and alignment in C++ too.

对于非POD类型似乎没有这样的要求，因此在这种情况下，允许实现使用不同的指针大小.您建议这样做不起作用，但请按照您的示例进行操作，

No such requirement seems to have been made for non-POD types, so an implementation would be allowed to use different pointer sizes in that case. You suggest that that cannot work, but to follow your example,

struct G { };
struct H : G { };

struct W
{
  virtual G* f() { ... }
};
struct X : W
{
  virtual H* f() { ... }
};

可以翻译成(伪代码)

struct W
{
  virtual G* f() { ... }
};
struct X : W
{
  override G* f() { ... }
  inline H* __X_f() { return static_cast<H *>(f()); }
};

仍然符合该语言的要求.

which would still match the requirements of the language.

两个指向结构类型的指针可能不同的有效原因是，将C ++编译器移植到具有现有C编译器且ABI设计不良的平台上. G是POD类型，因此G *必须与C中的内容完全相同.H不是POD类型，因此H *不需要与任何C类型匹配.

A valid reason why two pointers to structure types might not be identical is when a C++ compiler would be ported to a platform that has an existing C compiler with a poorly-designed ABI. G is a POD type, so G * needs to be exactly what it is in C. H is not a POD type, so H * does not need to match any C type.

对于对齐，这实际上可能会发生:实际发生的事情是，即使处理器的首选对齐方式实际上是，典型的GNU/Linux系统上的x86-32 ABI要求64位整数类型必须是32位对齐的. 64位.现在出现了另一个实现者，他们决定确实需要64位对齐，但是如果他们想与现有实现保持兼容，就会陷入困境.

For alignment, that can actually happen: something that really happened is that the x86-32 ABI on a typical GNU/Linux system requires 64-bit integer types to be 32-bit aligned, even though the processor's preferred alignment is actually 64-bit. Now comes another implementer, and they decide that they do want to require 64-bit alignment, but are stuck if they want to remain compatible with the existing implementation.

对于尺寸，我无法想到会发生这种情况的合理情况，但是我不确定这是否可能是我缺乏想象力的原因.

For sizes, I cannot think of a reasonable scenario in which it would happen, but I am unsure whether that might be a lack of imagination on my part.

这篇关于指向非工会类的指针的大小可以不同吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！