Win32平台下的微软C编译器的对齐策略

引言



首先看一个C语言下结构体的小程序。

#include<stdio.h>

struct StudentInfo {
    char i;
    int j;

};

void main() {

    printf("%d\n",sizeof(struct StudentInfo));

}

输出结果:8

不解,以为是5。其实这涉及到计算机内存对齐的问题,在计算机组成原理中有介绍。

概述



许多实际的计算机系统对基本类型数据在内存中存放的位置有限制,它们会要求这些数据的首地址的值是某个数k(通常它为4或8)的倍数,这就是所谓的内存对齐,而这个k则被称为该数据类型的对齐模数(alignment modulus)。当一种类型S的对齐模数与另一种类型T的对齐模数的比值是大于1的整数,我们就称类型S的对齐要求比T强(严格),而称T比S弱(宽松)。这种强制的要求一来简化了处理器与内存之间传输系统的设计,二来可以提升读取数据的速度。比如这么一种处理器,它每次读写内存的时候都从某个8倍数的地址开始,一次读出或写入8个字节的数据,假如软件能保证double类型的数据都从8倍数地址开始,那么读或写一个double类型数据就只需要一次内存操作。否则,我们就可能需要两次内存操作才能完成这个动作,因为数据或许恰好横跨在两个符合对齐要求的8字节内存块上。某些处理器在数据不满足对齐要求的情况下可能会出错,但是Intel的IA32架构的处理器则不管数据是否对齐都能正确工作。不过Intel奉劝大家,如果想提升性能,那么所有的程序数据都应该尽可能地对齐。

VC编辑器下的内存对齐



ANSI C标准中并没有规定,相邻声明的变量在内存中一定要相邻。为了程序的高效性,内存对齐问题由编译器自行灵活处理,这样导致相邻的变量之间可能会有一些填充字节。对于基本数据类型(int char),他们占用的内存空间在一个确定硬件系统下有个确定的值,所以,接下来我们只是考虑结构体成员内存分配情况。

Win32平台下的微软C编译器(cl.exe for 80×86)的对齐策略:1) 结构体变量的首地址能够被其最宽基本类型成员的大小所整除;备注:编译器在给结构体开辟空间时,首先找到结构体中最宽的基本数据类型,然后寻找内存地址能被该基本数据类型所整除的位置,作为结构体的首地址。将这个最宽的基本数据类型的大小作为上面介绍的对齐模数。2) 结构体每个成员相对于结构体首地址的偏移量(offset)都是成员大小的整数倍,如有需要编译器会在成员之间加上填充字节(internal adding);备注:为结构体的一个成员开辟空间之前,编译器首先检查预开辟空间的首地址相对于结构体首地址的偏移是否是本成员的整数倍,若是,则存放本成员,反之,则在本成员和上一个成员之间填充一定的字节,以达到整数倍的要求,也就是将预开辟空间的首地址后移几个字节。3) 结构体的总大小为结构体最宽基本类型成员大小的整数倍,如有需要,编译器会在最末一个成员之后加上填充字节(trailing padding)。备注:结构体总大小是包括填充字节,最后一个成员满足上面两条以外,还必须满足第三条,否则就必须在最后填充几个字节以达到本条要求。

结构体的内存对齐规则

1)结构体成员按低地址到高地址的顺序存储在内存, 即按声明的顺序存储2)每个成员的地址必须满足: 是 sizeof(该成员) 的整数倍3)总的字节数是 最大内置(就是基本类型)成员所占的字节数的 整数倍

 

Win32平台下的微软C编译器的对齐策略

时间: 2024-08-02 10:02:55

Win32平台下的微软C编译器的对齐策略的相关文章

WinCE平台的程序编译到Win32平台下运行

最近做的项目中,有一个在WinCE平台上跑的程序,后来随着项目的发展,要求此程序在PC上也能跑.感谢VS 2005提供的多平台支持,只需要几分钟就可以解决这个问题,方法很简单,下面是我处理的过程. 1.在配置管理中增加新平台 1.1 创建新平台 程序最初是基于Pocket PC 2003(ARMV4)平台创建的,我在此平台的配置基础上,创建新的Win32平台.打开菜单Build->Configuration Manager,在Active Solution Platform下拉选择框中选择New

.net平台下垃圾回收机制

引言:使用c++进行编程,内存的处理绝对是让每个程序设计者最头疼的一块了.但是对于.net平台下使用c#语言开发系统,内存管理可以说已经不算是问题了.在.net平台下CLR负责管理内存,CLR中的垃圾收集器GC:Garbage Collection,负责执行内存的清理工作,但是GC也只是负责清理托管堆上的垃圾对象,而对于非托管的资源对象,GC则不起作用,必须要程序开发者手动清理.此处需要稍微说明:一般而言,非托管资源主要包括数据库链接.文件句柄.COM对象.套接字.GDI+对象.互斥体等等. 在

(转).net平台下垃圾回收机制

引言:使用c++进行编程,内存的处理绝对是让每个程序设计者最头疼的一块了.但是对于.net平台下使用c#语言开发系统,内存管理可以说已经不算是问题了.在.net平台下CLR负责管理内存,CLR中的垃圾收集器GC:Garbage Collection,负责执行内存的清理工作,但是GC也只是负责清理托管堆上的垃圾对象,而对于非托管的资源对象,GC则不起作用,必须要程序开发者手动清理.此处需要稍微说明:一般而言,非托管资源主要包括数据库链接.文件句柄.COM对象.套接字.GDI+对象.互斥体等等. 在

在 Linux 平台下使用 JNI

引言 Java 的出现给大家开发带来的极大的方便.但是,如果我们有大量原有的经过广泛测试的非 Java 代码,将它们全部用 Java 来重写,恐怕会带来巨大的工作量和长期的测试:如果我们的应用中需要访问到特定的设备,甚至是仅符合公司内部信息交互规范的设备,或某个特定的操作系统才有的特性,Java 就显得有些力不从心了.面对这些问题,Sun 公司在 JDK1.0 中就定义了 JNI 规范,它规定了 Java 应用程序对本地方法的调用规则. 实现步骤及相关函数使用 本文将一步步说明在 Linux 平

编译FFmpeg的win32平台库

一.目的 FFmpeg是一套可以用来录制.转码音视频,并能将其转化为流的开源流媒体程序.采用LGPL或GPL许可证.它包含了非常先进的音频/视频编解码库,为了保证高可移植性和编解码质量,里面的很多代码都是从头开发的. FFmpeg是在Linux平台下开发的,如果想要编译出在Windows平台下使用的库,一种方法是使用交叉编译.网上有一个人叫zeranoe,他提供了FFmpeg的Windows平台开发SDK(网址:https://ffmpeg.zeranoe.com/builds/),同时他也提供

windows平台下基于VisualStudio的Clang安装和配置

LLVM 是一个开源的编译器架构,它已经被成功应用到多个应用领域.Clang是 LLVM 的一个编译器前端,它目前支持 C, C++, Objective-C 以及 Objective-C++ 等编程语言.Clang 对源程序进行词法分析和语义分析,并将分析结果转换为 AST ( 抽象语法树 ) ,最后使用 LLVM 作为后端代码的生成器. Clang 的开发目标是提供一个可以替代 GCC 的前端编译器.与 GCC 相比,Clang 是一个重新设计的编译器前端,具有一系列优点,例如模块化,代码简

Office文件的奥秘——.NET平台下不借助Office实现Word、Powerpoint等文件的解析

Office文件的奥秘——.NET平台下不借助Office实现Word.Powerpoint等文件的解析 分类: 技术 2013-07-26 15:38 852人阅读 评论(0) 收藏 举报 OfficePowerPointWord格式解析 转载http://www.cnblogs.com/mayswind/archive/2013/03/17/2962205.html [题外话] 这是2010年参加比赛时候做的研究,当时为了实现对Word.Excel.PowerPoint文件文字内容的抽取研究

将libvex移植到Visual Studio编译平台下的经验总结

1. 两难 将libvex从Linux移植到Windows,移植工作聚集于Cross-Compiler,而不是预料的Cross-Platform. VC++ Compiler到目前为止只支持C89标准,而这个标准规定,变量必须在代码块(即通过大括号包围起来的代码块)的最前面声明,参考 http://stackoverflow.com/questions/13308944/how-to-simulate-c99-in-visual-studio-for-variables-declaration

在Window平台下安装xgboost的Python版本

原文:http://blog.csdn.net/pengyulong/article/details/50515916 原文修改了两个地方才安装成功,第3步可以不用,第2步重新生成所有的就行了. 第4步,有“xgboost_wrapper.dll”以后,将该文件复制到/python-package/xgboost/中,继续后面步骤就可以了. 特别注意如果你的python是32位的,第二步就不要选择x64,而是选择win32.对应的文件也不是在x64下了.一定可以运行. xgboost的全称是eX