struct中的size_t [英] size_t in a struct

查看:80
本文介绍了struct中的size_t的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为了避免在结构中填充,放置size_t

变量的最佳位置在哪里?


根据常见问题2.12( http://c-faq.com/struct/padding.html)

它说:


如果你担心浪费的空间,你可以最大限度地减少

填充的影响订购结构的成员基于他们的基础

类型,从最大到最小。


所以,如果我有以下内容:


typedef struct _Buffer_t {


char * buffer;

size_t size;


} Buffer_t;


我应该使用mimized padding,因为size_t是unsigned long。

但是,size_t会变成unsigned long long吗?如果确实如此,

那么size_t仍然不会比系统上的指针大,

对吗?但是我应该把size_t放在其他整数

声明中?

建筑结构时,我是否应该假设size_t是无符号的长?


现在,如果我做了另一个结构:


typedef struct _Buffer2_t {


Buffer_t名称;

char * buffer;

size_t size;


} Buffer2_t;


以上仍然是最小化填充的正确顺序吗?


谢谢。

To avoid padding in structures, where is the best place to put size_t
variables?

According the faq question 2.12 (http://c-faq.com/struct/padding.html),
it says:

"If you''re worried about wasted space, you can minimize the effects of
padding by ordering the members of a structure based on their base
types, from largest to smallest."

So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.
However, will size_t ever become an unsigned long long? If it does,
then size_t still wouldn''t be larger than a pointer on the system,
right? But where should I put size_t in relation to other integer
declarations? Should I all ways assume size_t is an unsigned long when
building structures?

Now, if I made another structure:

typedef struct _Buffer2_t {

Buffer_t name;
char *buffer;
size_t size;

} Buffer2_t;

Is the above still the correct sequence to minimize padding?

Thanks.

推荐答案

bw ***** @ yahoo .com 写道:

为了避免在结构中填充,放置size_t

变量的最佳位置在哪里? />

根据常见问题2.12( http ://c-faq.com/struct/padding.html)

它说:


如果你是担心浪费空间,你可以通过订购m来最小化

填充的影响基于其基础的结构的余烬

类型,从最大到最小。
To avoid padding in structures, where is the best place to put size_t
variables?

According the faq question 2.12 (http://c-faq.com/struct/padding.html),
it says:

"If you''re worried about wasted space, you can minimize the effects of
padding by ordering the members of a structure based on their base
types, from largest to smallest."



一般来说,这是一个很好的建议。但是不同的类型在不同的编译器上有不同的大小

。如果最小化空间很重要,那么你需要为你将代码移植到的每个编译器自定义布局。

In general this is good advice. But different types have different sizes
on different compilers. If minimising the space is important, you would
have to customise the layout for each compiler you port the code to.


所以,如果我有以下内容:


typedef struct _Buffer_t {

char * buffer;

size_t size;


} Buffer_t;


我应该使用mimized padding,因为size_t是无符号长整数。
So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.



不一定! size_t可能等同于unsigned short,unsigned

int,unsigned long,unsigned long long或其他一些
实现定义的整数类型。它甚至可能比未签名的长b长,但不超过uintmax_t。


此外,指针可能有各种不同的大小。测试

我碰巧在这里有三个不同的编译器,我可以有16位,

32位和64位指向char的指针。


在大多数情况下,你会发现任何给定系统的char *和size_t在

上具有相同的大小。我想到的一个例外是Turbo C的''巨大''

内存模型,其中char *是4个字节但size_t是2.

Not necessarily! size_t may be equivalent to unsigned short, unsigned
int, unsigned long, unsigned long long or some other
implementation-defined integer type. It may even be longer than unsigned
long long, but no longer than uintmax_t.

In addition, the pointer may be of various different sizes. Testing
three different compilers I happen to have here, I can have 16-bit,
32-bit and 64-bit pointers to char.

In most cases you''ll find that char* and size_t have the same size on
any given system. One exception that comes to mind is Turbo C''s ''huge''
memory model, where char* is 4 bytes but size_t is 2.


但是,size_t会不会成为无符号多长?如果确实如此,

那么size_t仍然不会比系统上的指针大,

对吗?但是我应该把size_t放在其他整数

声明中?我是否应该假设size_t是一个无符号长的

建筑结构?
However, will size_t ever become an unsigned long long? If it does,
then size_t still wouldn''t be larger than a pointer on the system,
right? But where should I put size_t in relation to other integer
declarations? Should I all ways assume size_t is an unsigned long when
building structures?



如果对您来说很重要,您可以测试

特定系统的大小并生成所需的代码。

If it matters that much to you, you could test the size on the
particular system and generate the required code.


现在,如果我做了另一个结构:


typedef struct _Buffer2_t {


Buffer_t姓名;

char * buffer;

size_t size;


} Buffer2_t;


以上仍然是最小化填充的正确顺序吗?
Now, if I made another structure:

typedef struct _Buffer2_t {

Buffer_t name;
char *buffer;
size_t size;

} Buffer2_t;

Is the above still the correct sequence to minimize padding?



单个Buffer2_t结构可能具有相同数量的填充

作为两个Buffer_t结构,因为它基本上只是两个相同的

的事情,一个接一个。将''name''成员放在最后

可能对整体大小没有任何影响。


-

Simon。

A single Buffer2_t struct will probably have the same amount of padding
as two Buffer_t structs, since it is basically just two of the same
thing, one after the other. Putting the ''name'' member at the end
probably wouldn''t make any difference to the overall size.

--
Simon.


>根据常见问题2.12( http://c-faq.com/struct/padding.html)
>According the faq question 2.12 (http://c-faq.com/struct/padding.html),

> ;它说:

如果你担心浪费的空间,你可以通过根据他们的基础订购结构的成员来最小化
填充的影响
类型,从最大到最小。
>it says:

"If you''re worried about wasted space, you can minimize the effects of
padding by ordering the members of a structure based on their base
types, from largest to smallest."



我不同意这一点,我不认为它会起作用,当涉及到b
指针时。例如,short更可能比指向任何东西的指针小得多b
。 "指针" isn''ta

基本类型但如果你认为它在这里工作得更好。

I don''t agree with this, and I don''t think it will work, when
pointers are involved. For example, a short is more likely to be
smaller than a pointer to anything, even char. "pointer" isn''t a
base type but things work better here if you assume it is.


>所以,如果我有以下内容:

typedef struct _Buffer_t {

char * buffer;

size_t size;

} Buffer_t;

我应该用mimized padding,因为size_t是一个无符号长整数。
但是,size_t会变成unsigned long long吗?如果是,
>So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.
However, will size_t ever become an unsigned long long? If it does,



可能。在64位

指针的架构上,我不会感到惊讶,但尝试保持类型与旧版本的旧系统保持长时间相同的长度为32比特。

Probably. It wouldn''t surprise me on an architecture with 64-bit
pointers but an attempt to keep types like long the same as the
older legacy system keeps long at 32 bits.


>然后size_t仍然不会大于系统上的指针,对吧?
>then size_t still wouldn''t be larger than a pointer on the system,
right?



没有保证,但这是一个非常安全的赌注。而且,输掉赌注的罚金很少:结构填充浪费了一些内存但没有未定义的行为。

No guarantees, but it''s a pretty safe bet. And the penalties for
losing the bet are minimal: structure padding wastes a bit of
memory but no undefined behavior.


>但是我应该把size_t放在其他整数
声明中?
建筑结构时,我是否应该假设size_t是无符号长的?
>But where should I put size_t in relation to other integer
declarations? Should I all ways assume size_t is an unsigned long when
building structures?



为了订购,您可能会认为size_t略大或略小于
而不是unsigned long。交替

size_t和unsigned long将倾向于最大化填充,如果他们

的大小不同。


假设size_t如果您认为您的代码更多,那么稍微大一些可能会在较新的系统上运行,其中size_t和unsigned long long

可能是64位。如果你的代码更有可能在size_t

可能是16位的旧系统上运行,假设size_t略小于unsigned

long。


还有其他地方你有类似的问题,比如

相对大小为double和指针,或者是double和unsigned long

long。


无论哪种方式,几乎可以肯定你会错误的一些

时间。你仍然可以尝试做一个相当不错的百分比

当时。

You may assume that size_t is slightly larger or slightly smaller
than an unsigned long for the purpose of the ordering. Alternating
size_t and unsigned long would tend to maximize padding if they
aren''t the same size.

Assume size_t is slightly larger if you think your code will more
likely run on newer systems where size_t and unsigned long long
might be 64 bit. Assume size_t is slightly smaller than unsigned
long if your code will more likely run on older systems where size_t
might be 16 bits.

There are other places where you have similar problems, such as the
relative size of double and pointer or double and unsigned long
long.

Either way, it is virtually certain you WILL be wrong some of the
time. You can still try for being right a pretty good percentage
of the time.


>现在,如果我做的话另一种结构:

typedef struct _Buffer2_t {


Buffer_t名称;

char * buffer;

size_t size;

} Buffer2_t;

以上仍然是最小化填充的正确顺序吗?
>Now, if I made another structure:

typedef struct _Buffer2_t {

Buffer_t name;
char *buffer;
size_t size;

} Buffer2_t;

Is the above still the correct sequence to minimize padding?



没有一个正确的序列。不过这个是合理的

猜测。

There is no single correct sequence. That one is a reasonable
guess, though.




Simon Biber写道:

Simon Biber wrote:

如果我有以下内容:


typedef struct _Buffer_t {


char * buffer;

size_t size;


} Buffer_t;


我应该有模仿填充,因为size_t是无符号长整数。
So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.



不一定! size_t可能等同于unsigned short,unsigned

int,unsigned long,unsigned long long或其他一些
实现定义的整数类型。它甚至可能长于未签名的长期b / b
,但不会超过uintmax_t。


Not necessarily! size_t may be equivalent to unsigned short, unsigned
int, unsigned long, unsigned long long or some other
implementation-defined integer type. It may even be longer than unsigned
long long, but no longer than uintmax_t.



标准方面,如何处理结构中的size_t以最小化

填充?在结构中的指针后,size_t是否应该遵循?

如果我在结构中有整数,我应该把size_t放在哪里?


< OT>

根据我的style(9)手册页,建议是:


"在结构中声明变量时,声明它们按使用排序,

然后

按大小(从大到小),然后按字母顺序排列。


这会导致填充,对吧?但是我必须假设size_t的大小为

才能遵循这种风格。

< / OT>


谢谢。

So standard-wise, how do I handle size_t in structures to minmize
padding? Should size_t all ways follow after pointers in structures?
And if I have integers in the structure, where should I put size_t?

<OT>
According my style(9) man page, the suggestion is to:

"When declaring variables in structures, declare them sorted by use,
then
by size (largest to smallest), then by alphabetical order. "

This would lead to padding, right? But I would have to assume a size
for size_t to follow that style.
</OT>

Thanks.


这篇关于struct中的size_t的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆