union的妙用在于各成员存储在同一空间,我们可以通过union取成员操作得到内存中各位的存储模式,否则你需要一大堆位运算操作取中间的几位。节省操作!
#include<stdio.h>
union bits32_tag {
int whole; //一个32位的值
struct { char c0, c1, c2, c3;} byte; //四个八位的字节
} value;
int main()
{
value.whole = 0x45494647;
printf("%c",value.byte.c0);
printf("%c",value.byte.c1);
printf("%c",value.byte.c2);
printf("%c",value.byte.c3);
}
小端的机器上16进制的47置c0(对应的ASCII是G)同理可得c1=‘F’,c2=‘I’,c3=‘E’
GFIE
有时候总会看到int ch的原因?
while((ch=getchar())!=EOF)
linux下EOF的输入是以Ctrl+D而不是Ctrl+Z
其中 EOF=-1,getchar()函数的返回值也是int型,若ch是int型则和EOF 比较很正常,但若是char型有两点坏处1–>>ch从getchar()截取1个字节,(是的,这里getchar()会有可能接收到比ascii码255以上的字符)再因为运算升级为int之后才去和EOF比较,而不一定是原来"正宗"得到的字符跟EOF比较。2–>>打印一下char ch 下的得到的EOF,以c%打印,出现了神奇的’�’,而(int)ch即强制转换后得到的才是-1
#include<stdio.h>
int main()
{
char ch;
while((ch=getchar())!=EOF)
continue;
printf("%c",ch);
printf("%d",(int)ch);
}
但是我认为正常情况下在你的输入都是ascii码的情况下两种情况貌似没太大区别,我试了大部分字符没啥问题。
如果继续研究EOF(END OF FILE),你会发现一个很好玩的现象。
因为读取失败,getchar()返回一个-1,ctrl+d其实仍在输入流里
#include<stdio.h>
int main()
{
int ch;
while((ch=getchar())!=EOF)
{
continue;
}
printf("%c",(char)ch);
printf("A");
getchar();
getchar();
char*s;
scanf("%s",s);
printf("%s",s);
printf("A");
getchar();
}
打印结果是�A(null)A
因为停留在输入缓冲里的ctrl+d无法被读取,随后的getchar(),scanf()都失效了—>甚至printf冒出一个奇怪的(null),(其余的pintf正常运行)之后程序结束,END OF FILE
这个ctrl+D仿佛拥有了屏蔽输入流的作用。