记得以前曾经两次谈到过内存对齐话题，一次在’也谈内存对齐‘一文中，另一次则是’也谈内存对齐(续)’，今天下午和同事又谈到内存对齐的问题了，遂想继续挖掘下去，看看其背后的故事。 关于内存对齐的中文文章多在介绍对齐的’法则’，比如为什么sizeof(T)和我们估计的T的大小有出入呢等等，而对于内存对齐的本质少有介绍，我在Google上搜索了一阵后，在IBM开发社区上发现一篇叫’Data alignment: Straighten up and fly right‘的文章，其中就有我想知道的关于’内存对齐背后的故事’，下面的很多内容都是来自那篇文章的。 ...
关于内存对齐的话题，始终是敏感的。稍有不慎，必将闯下大祸！最近项目稍显轻闲，自己给自己安排一天反思和总结一下，突然想到以前写过的一篇’也谈内存对齐’，那篇文章谈的是内存对齐的基本知识以及一些实验的数据，想必很多人看完后，会收获一些东西，但是对内存对齐的应用还是处于懵懂状态，其实大部分时间我们是不会显式的用到’内存对齐的’，但是有些时候我们需要这样做。这里做了一个小例子，希望能给大家以启发。 ...
到底需不需要编译器之外的独立的静态代码检查工具呢？这个问题’仁者见仁，智者见智’。但是有一个结论我想大家都会认可，那就是越是在开发周期早期发现的Bug，修复它所付出的代价就越小。而像lint这样的静态代码检查程序恰恰是让Bug在早期阶段’显露原型’的绝佳工具，而追求’lint-clean’[注1]境界的代码也向来是专家级程序员的嗜好。别忘了在’C专家编程’一书中曾经提到Sun OS的内核一直是保持’lint-clean’状态的，这就是榜样！还等什么？赶快学呀！^_^ ...
在最近的项目中，我们涉及到了“内存对齐”技术。对于大部分程序员来说，“内存对齐”对他们来说都应该是“透明的”。“内存对齐”应该是编译器的“管辖范围”。编译器为程序中的每个“数据单元”安排在适当的位置上。但是C语言的一个特点就是太灵活，太强大，它允许你干预“内存对齐”。如果你想了解更加底层的秘密，“内存对齐”对你就不应该再透明了。 一、内存对齐的原因 大部分的参考资料都是如是说的： 1、平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。 2、性能原因：数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。 ...