C++ 的大小64 位环境与 32 位环境中的数组

发布于 2024-09-27 07:44:48 字数 394 浏览 1 评论 0原文

假设我有一个类定义如下,

class foo
{
    char [10] bar;
}

假设没有填充/打包,与 32 位环境相比,在 64 位环境中该类的大小有何不同。

我相信该类的 64 位版本的长度将多 4 个字节,因为:

  1. 该类必须包含一个 char* 才能指向数组的开头 bar
  2. char* 在 64 位环境中是 8 个字节,而在 64 位环境中是 4 个字节在 32 位环境中

我正确吗?

谢谢!

关于数组实际如何工作的进一步问题 如果声明数组时没有存储指针,那么如何从数组名称中获取地址并执行 bar[0]、bar[1] 等操作?

suppose I have a class defined as follows

class foo
{
    char [10] bar;
}

How would the size of this class differ when in a 64 bit environment compared to a 32 bit one, assuming no padding/packing.

I believe the 64 bit version of the class would be 4 more bytes in length since:

  1. The class must contain a char* in order to point to the start of the array bar
  2. an char* is 8 bytes in a 64 bit environment vs 4 bytes in a 32 bit environment

Am I correct?

Thanks!

A further question about how arrays actually work
If there is no pointer stored when you declare an array, how come you can get an address out of the array name and do things like bar[0], bar[1], etc?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

雨落□心尘 2024-10-04 07:44:48

不,你不是。 char [] bar; 甚至无法编译,char bar[10]; 是正确的语法,不,不存储指针,sizeof(char) 始终是1 和 sizeof bar 将为 10,无论架构如何。

现在回答你的附加问题:
您必须了解左值和右值以及左值到右值转换的概念。通常左值到右值的转换“不执行任何操作”。一个例外是 T 数组的左值到右值转换是转换为指向 T 的指针,该指针指向数组的第一个元素。

此外,采用 T 数组值的函数声明相当于采用指向 T 的指针的函数声明。

No you are not. char [] bar; won't even compile, char bar[10]; is the correct syntax, and no, no pointer is stored, sizeof(char) is always 1 and sizeof bar will be 10, regardless of the architecture.

Now for your additional question:
You must understand the notion of lvalues and rvalues and lvalue-to-rvalue conversions. Usually lvalue-to-rvalue conversions "do nothing". An excetion is that an lvalue-to-rvalue conversion for array of T is conversion to a pointer to T which points to the first element of the array.

Also a function declaration taking an array of T by value is equivalent to a function declaration taking a pointer to T.

忘你却要生生世世 2024-10-04 07:44:48

无论您的体系结构是什么,sizeof(char) 在 C++ 标准中都定义为 1。您的结构是一个 10 个字符的数组,而不是指向数组的指针。

另外,正确的声明应该是 char bar[10]

您可能正在考虑 char *bar - 现在这将是 32 位与 64 位中的 4 字节与 8 字节。

sizeof(char) is defined as 1 in the C++ standard, no matter what your architecture is. Your struct is an array of 10 chars, not a pointer to an array.

Also, the proper declaration would be char bar[10].

You're probably thinking about char *bar - now that would be a 4 bytes vs 8 bytes in 32-bit vs 64-bit.

十二 2024-10-04 07:44:48

您可能会看到差异的一种方法是,编译器决定在数组后面插入一些填充,这样如果您要创建这些对象的数组,每个对象都会很好地对齐。例如,在 32 位目标上,它可能会将其填充到 12 字节,但在 64 位目标上,它可能会填充到 16 字节。

然而,如果没有填充,两者的大小将相同——您没有定义指针,因此指针大小的差异在这里没有影响。

The one way you might see a difference would be if the compiler decided to insert some padding after the array so if you were to create an array of these objects, each would be nicely aligned. For example, on a 32-bit target it might pad it out to 12 bytes, but on a 64-bit target to 16 bytes instead.

Without padding, however, the two would be the same size -- you're not defining a pointer, so the difference in pointer size has no effect here.

中性美 2024-10-04 07:44:48

您给出的示例在 64 位环境中不会变大。

class foo
{
    char bar[10];
};

然而,它也毫无用处,因为它没有公共成员。

许多类看起来更像是这样的:

class foo2
{
public:
    char bar[10];
    virtual ~foo2() {}
};

具有任何虚拟成员的类(例如 foo2)将随着指针大小的增长而增长。然而,对于大多数编译器来说,无论有多少虚拟成员,都只有一个指针。

无论哪种方式,这只是您创建大量(> 20000 个实例)的类的问题。

The example you give will not become larger on a 64-bit environment.

class foo
{
    char bar[10];
};

However, it's also quite useless because it has no public members.

Many classes look more like this:

class foo2
{
public:
    char bar[10];
    virtual ~foo2() {}
};

A class with any virtual members at all, such as foo2 has, will grow when the pointer size grows. However, with most compilers, there is only one pointer regardless of how many virtual members.

Either way, it's only a concern for classes that you create a large number of (> say 20000 instances).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文