Compiler

关于内存对齐的话题，始终是敏感的。稍有不慎，必将闯下大祸！最近项目稍显轻闲，自己给自己安排一天反思和总结一下，突然想到以前写过的一篇’也谈内存对齐’，那篇文章谈的是内存对齐的基本知识以及一些实验的数据，想必很多人看完后，会收获一些东西，但是对内存对齐的应用还是处于懵懂状态，其实大部分时间我们是不会显式的用到’内存对齐的’，但是有些时候我们需要这样做。这里做了一个小例子，希望能给大家以启发。 ...

到底需不需要编译器之外的独立的静态代码检查工具呢？这个问题’仁者见仁，智者见智’。但是有一个结论我想大家都会认可，那就是越是在开发周期早期发现的Bug，修复它所付出的代价就越小。而像lint这样的静态代码检查程序恰恰是让Bug在早期阶段’显露原型’的绝佳工具，而追求’lint-clean’[注1]境界的代码也向来是专家级程序员的嗜好。别忘了在’C专家编程’一书中曾经提到Sun OS的内核一直是保持’lint-clean’状态的，这就是榜样！还等什么？赶快学呀！^_^ ...

看了dreamhead的那篇“差异程序员”，又恰逢在今天dreamhead在一封邮件中谈到其继续深入“向下学习”的想法，心里突然有了本篇题目这样的一个话题。 ...

在最近的项目中，我们涉及到了“内存对齐”技术。对于大部分程序员来说，“内存对齐”对他们来说都应该是“透明的”。“内存对齐”应该是编译器的“管辖范围”。编译器为程序中的每个“数据单元”安排在适当的位置上。但是C语言的一个特点就是太灵活，太强大，它允许你干预“内存对齐”。如果你想了解更加底层的秘密，“内存对齐”对你就不应该再透明了。 一、内存对齐的原因 大部分的参考资料都是如是说的： 1、平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。 2、性能原因：数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。 ...