最近在思考改进项目中一模块的实现，该模块维护起来让我很是头疼，所有才有了整体换掉它的想法。设计和实现中利用了内存对齐的技术。关于内存对齐，我曾经写过三篇文章，第一篇介绍了计算内存对齐的方法和例子，第二篇说了一个内存对齐的应用；三谈内存对齐时，则从其本质上做了阐述，而这次实际上是继续在其本质上的做文章，结合本质谈谈为什么内存对齐的计算方法就应该是第一篇中所讲的那两条。 如果对内存对齐本质还不清楚的话，就看看我的内存对齐系列的第三篇吧。如果你清楚了本质，那么我们结合第一篇中交待的内存对齐计算方法来进一步探究，为什么计算的方法就是这个样子的。 ...
记得以前曾经两次谈到过内存对齐话题，一次在’也谈内存对齐‘一文中，另一次则是’也谈内存对齐(续)’，今天下午和同事又谈到内存对齐的问题了，遂想继续挖掘下去，看看其背后的故事。 关于内存对齐的中文文章多在介绍对齐的’法则’，比如为什么sizeof(T)和我们估计的T的大小有出入呢等等，而对于内存对齐的本质少有介绍，我在Google上搜索了一阵后，在IBM开发社区上发现一篇叫’Data alignment: Straighten up and fly right‘的文章，其中就有我想知道的关于’内存对齐背后的故事’，下面的很多内容都是来自那篇文章的。 ...
关于内存对齐的话题，始终是敏感的。稍有不慎，必将闯下大祸！最近项目稍显轻闲，自己给自己安排一天反思和总结一下，突然想到以前写过的一篇’也谈内存对齐’，那篇文章谈的是内存对齐的基本知识以及一些实验的数据，想必很多人看完后，会收获一些东西，但是对内存对齐的应用还是处于懵懂状态，其实大部分时间我们是不会显式的用到’内存对齐的’，但是有些时候我们需要这样做。这里做了一个小例子，希望能给大家以启发。 ...
离我的上一篇BLOG已经时隔一个月有余，项目忙是一方面原因，最主要的还是自己没什么“收获”。在最近的项目中总是和内存打交道，时间长了，便有了些许问题，原本我就不是不求甚解者，遂趁此机会又复习了些内存相关资料。 ...
在最近的项目中，我们涉及到了“内存对齐”技术。对于大部分程序员来说，“内存对齐”对他们来说都应该是“透明的”。“内存对齐”应该是编译器的“管辖范围”。编译器为程序中的每个“数据单元”安排在适当的位置上。但是C语言的一个特点就是太灵活，太强大，它允许你干预“内存对齐”。如果你想了解更加底层的秘密，“内存对齐”对你就不应该再透明了。 一、内存对齐的原因 大部分的参考资料都是如是说的： 1、平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。 2、性能原因：数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。 ...