什么是输出 [英] What's the output
问题描述
int main（）
{
int k;
union jatin {
int i：5 ;
char j：2;
};
union jatin rajpal;
k = sizeof （rajpal）;
printf（"％d"，k）;
返回0;
}
&如果在上面的例子中代替union，那将是什么输出如果
我将使用struct？任何人都可以解释我的工会行为。
int main()
{
int k;
union jatin{
int i :5;
char j :2;
};
union jatin rajpal;
k= sizeof(rajpal);
printf("%d",k);
return 0;
}
& what would be the output if instead of union in the above example if
i''ll use struct? Could anyon can explain me union behavior.
推荐答案
ra ********** @ yahoo.co.in 写道：
int main （）
{
int k;
union jatin {
int i：5;
char j：2;
};
union jatin rajpal;
k = sizeof（rajpal）;
printf（"％d"，k）;
返回0;
}
int main()
{
int k;
union jatin{
int i :5;
char j :2;
};
union jatin rajpal;
k= sizeof(rajpal);
printf("%d",k);
return 0;
}
你看到了什么，你期待什么？
What did you see and what did you expect?
&如果在上面的例子中代替union，那将是什么输出如果
我将使用struct？任何人都可以解释我的工会行为。
& what would be the output if instead of union in the above example if
i''ll use struct? Could anyon can explain me union behavior.
你的理解是什么？你的教科书应该尽早解释。
-
Ian Collins。
What is your understanding? Your text book should explain this early on.
--
Ian Collins.
On 2月28日下午5:34，rajpal_ja ... @ yahoo.co.in写道：
On Feb 28, 5:34 pm, rajpal_ja...@yahoo.co.in wrote:
int main（）
{
int k;
union jatin {
int i：5;
char j：2;
};
union jatin rajpal;
k = sizeof（rajpal）;
printf （"％d"，k）;
返回0;
}
int main()
{
int k;
union jatin{
int i :5;
char j :2;
};
union jatin rajpal;
k= sizeof(rajpal);
printf("%d",k);
return 0;
}
它将是集合中最大对象的大小。
It will be the size of the largest object in the collection.
&如果在上面的例子中代替union，那将是什么输出如果
我将使用struct？
& what would be the output if instead of union in the above example if
i''ll use struct?
它将是所有结构成员总和的大小，加上填充。
It will be the size of the sum of all struct members, plus padding.
可以任意可以解释我的工会行为。
Could anyon can explain me union behavior.
好的C书应该做得很好。你读过K& R2吗？
A good C book should do nicely. Have you read K&R2?
文章< 11 ******************* ***@p10g2000cwp.googlegroups .com> ;,
< ra ********** @ yahoo.co.inwrote：
In article <11**********************@p10g2000cwp.googlegroups .com>,
<ra**********@yahoo.co.inwrote:
> int main（）
{
int k;
union jatin {
int i：5;
char j：2;
};
>int main()
{
int k;
union jatin{
int i :5;
char j :2;
};
> union jatin rajpal;
k = sizeof（rajpal）;
printf（"％d"，k ）;
返回0;
}
>union jatin rajpal;
k= sizeof(rajpal);
printf("%d",k);
return 0;
}
你还没有包括< stdio.h>，所以你可以得到任何输出
printf由于缺少printf的原型。
You haven''t included <stdio.h>, so you could get any output from
the printf due to the lack of the prototype for the printf.
>&如果在上面的例子中代替union，那将是什么输出？如果我将使用struct？任何人都可以解释我的工会行为。
>& what would be the output if instead of union in the above example if
i''ll use struct? Could anyon can explain me union behavior.
在所有情况下，在我测试的编译器上，我输出4作为
输出 - 这是sizeof（int ）在那个特定的机器上。
我还得到一个警告，char是一个非标准类型的位域。
C99标准允许其他位域类型比int和unsigned int，
作为系统扩展，但没有定义它们的行为。
在union情况下，编译器正在分配足够的空间
表示完整的int。没有要求编译器分配
尽可能小的空间来保存定义的位域大小。
编写相关子句的方式，编译器将是
如果它总是使用与任何存储完全相同的大小
包含位域的单位。
非标准字符位字段在我正在使用的特定编译器上，没有比
一个int位域更多的空间，所以
没有必要为<分配大于int的任何东西br />
整体存储空间。但由于char位域是非标准的，如果编译器决定
需要为包含
标准就不会有任何抱怨>
a char bitfield - 非标准行为可能与编译器编写者想要的一样不同。
在结构案例中，你再次遇到问题那个char
位域是非标准的，所以你再次可以得到漂亮的
任何答案。如果编译器选择将它们视为int
bitfields，那么你再次遇到允许
编译器分配一个完整的单词来保存的行为
位域的总和，这些位域一起符合
a字的限制。我故意使用word字样这里非特定的是
而不是int，因为编译器不限于b的倍数。如果需要，编译器可以打包到
最小的整数类型，如果需要，允许使用完整的整数类型。
。
基本上，如果你正在寻找
中的某种承诺，那么bitfields的标准只会是一定的尺寸而且没有更大的b
大小将尽可能小，
然后你将找不到这些承诺。
唯一的承诺是，如果你使用int或signed int位域，
并且下一个位域适合同一个分配单元是
已经启动，然后它将被放入相同的分配单元。但是如果下一个位域不适合同一个分配单元那么
那么它b / b
取决于它是否跨越位域，每个位于每个位置/>两个存储单元中的
，或者如果它取消填充第一个
存储单元并为第二个位域启动一个新的存储单元。
如果你期望在如何处理
位域的细节方面具有可移植性，那么你应该停止期待。甚至没有任何关于位域是否开始从b开始填充的承诺开始。存储分配，或从b $ b开始填写结束的存储分配。在你的例子中，我可以在存储单元中的j之前或之后最终存储
，并且同一系统上的
下一个编译器版本可以将其切换为
另一种方式。 bitfields不是任何类型的便携式位级
存储规格。
-
有些想法如此错误，只有非常智能这个人
可以相信他们。 - George Orwell
In all the cases, on the compiler I was testing with, I get 4 as
the output -- which is sizeof(int) on that particular machine.
I also get a warning that char is a non-standard type for a bitfield.
The C99 standard permits bitfield types other than int and unsigned int,
as system extensions, but does not define their behaviour.
In the union case, the compiler is allocating enough space
for a full int. There is no requirement that the compiler allocate
the smallest possible space that would hold the defined bitfield sizes.
The way the relevant clauses are written, a compiler would be
conformant if it always used exactly the same size for any storage
unit that contained a bitfield.
The non-standard char bitfield does not take any more space than
an int bitfield on the particular compiler I am using, so there
there was no need to allocate anything bigger than an int for the
overall storage. But since char bitfields are non-standard, the
standard would have no complaint if a compiler decided that
it needed to allocate 742 bytes for every unit that contained
a char bitfield -- non-standard behaviour can be as unusual as
the compiler writer wants.
In the struct case, you again run into the problme that char
bitfields are non-standard, so you again could get out pretty
much any answer. If the compiler choose to treat them like int
bitfields, then you again encounter the behaviour that a
compiler is allowed to allocate a complete word to hold an
aggregate of bitfields that together fit within the limits of
a word. I am deliberately using "word" non-specifically here
rather than "int", as the compiler is not restricted to
multiples of "int". A compiler is allowed to pack down to
the smallest integral type if it wants, and it is allowed to
use a complete integral type if it wants.
Basically, if you are looking for some kind of promises in
the standards that bitfields will only be a certain size and no
bigger, or that the aggregate size will be as small as possible,
then you will not find those promises.
The only promise is that if you are using int or signed int bitfields,
and the next bitfield would fit within the same allocation unit was was
already started, then it will be put in the same allocation unit. But
if the next bitfield would not fit in the same allocation unit, then it
is up to the compiler as to whether it spans the bitfield, part in each
of the two storage units, or if it instead leaves off filling the first
storage unit and starts a new storage unit for the second bitfield.
If you are expecting portability in the fine details of how
bitfields are handled, then you should stop expecting that. There isn''t
even any promise about whether bitfields start filling from
the "beginning" of the storage allocation, or start filling from
the "end" of the storage allocation. In your example, i could
end up stored before or after j in the storage unit, and the
next compiler release on the same system could switch it to
the other way. bitfields are NOT any kind of portable bit-level
storage specification.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
这篇关于什么是输出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
