最近因为要做一点培训工作，激发了我攀爬制作演示文档这颗技能树的情绪， 因此在理论上生吞活剥了一些“别说你懂ppt”之类的东东，在实践上分别用 DrRacket的slideshow模块，\LaTex的beamer包，微软的PowerPoint做了一点点 实验。

用这些工具做“幻灯片”的时候，我对生吞活剥的那些理论产生了一点点怀疑， 那些理论无不强调利用视觉冲击表达、贩卖自己的观点，不过我的角色似乎不 是观点贩子，我们做技术培训或者技术分享的时候，并不是传递观念，而是传 递知识。

我对自己之前的误解于是有了一点理解，当大家谈论ppt、幻灯片、演示文档的 时候，往往是以presentation的背景去谈的，presentation一般来说，当然是 贩卖观点的，而presentation要借助presentation document，这个document用 ppt来做，那么如果其他什么活动需要用ppt来做，似乎就自然服从 presentation的法则了。

同样适用ppt制作文档的两类活动：教学和presentation，显然是非常大的，根 本区别就在于前者传递知识，后者传递观念。当然，这两者都需要调动视觉因 素，但因为目标的不同，又有很大的区别。教学活动适用视觉因素，更多的用 于为抽象内容提供直观印象，比方画出数据结构的示意图，画出算法在数据结 构上作用的示意图，这种视觉效果对于理解问题的帮助是其他方式无可比拟 （似乎如此）的；而presentation使用视觉因素主要在于强调，吸引受众的注 意力，通过视觉上的效果塑造某种观念，比方通过视觉上的先后，灌输逻辑上 的先后次序，等等。当然，presentation对视觉因素的使用，教学活动一般的 说，也不是用不上。

教学使用的幻灯片通常即便没有老师的讲解，也能传递相当含量的信息（知 识），而presentation使用的“演示文档”，很难想象会有这样的效果。因此， 对于教学活动来说，幻灯片应该被看做“教学材料”，某种意义上是“书”。 而presentation使用的幻灯片则是“戏法”。

技术报告、技术培训和技术分享，更近于教学活动而不是presentation，一个 精心设计的技术主题的幻灯片，应该可能在不需要讲解的情况下传递主要的知 识内容。

因此，技术主题的幻灯片和“演示文档”的制作有很大的不同。比方说，技术 主题幻灯片对于动画的使用，应该主要在内容上，而不是在形式上，比如以动 画演示cpu的工作方式，而不是以动画引入、加强一句判断。比方技术主题幻 灯片对于条列（itemize）环境的使用似乎应该少一些，幻灯片应该使用各种 元素来说清楚一个问题，而不是列举问题。

当然，在技术报告中可能仅仅使用幻灯片作为一个提纲，内容完全在报告者的 肚子里，这应该不属于讨论范围。

我一共使用了三种工具:DrRacket的slideshow模块，\LaTex的beamer包， PowerPoint。最终用beamer完成的幻灯片的制作。

DrRacket是一种Scheme的实现，它提供了一个做slideshow的库，同时也是一 种语言。完全编程的制作幻灯片，这个东东在概念上很有趣，画演示动画似乎 也有方便之处。但是……它在内容元素上太弱，比方说，没有引用环境，没有 代码条列环境，而且自己通过努力也不见得能做到。对于内容型slideshow来 说，这个是致命的缺点。

beamer用的人较多，各种问题基本都能得到解决，用pgf/TikZ能画很不错的 演示图/动画。问题是，画起来有些麻烦，编译太慢。但是TikZ能够做到的也 是比较惊艳的，比方说做手绘效果的元素，用decorate还是比较容易的，而 这个非常有趣—可能也有用的一种效果。

PowerPoint应该是比较好用的，但在画一些特定的东西上，还是不如TikZ方 便，比方说画树，ppt有一个节点一个节点的去拖，而TikZ就可以自动布局， 画数组的示意图之类的，ppt都要自己把矩形元素“粘”到一起，并不是特别 方便，画这类东西，矢量绘图语言往往比图形化的绘图工具方便一些。

至于制作要点，似乎和网上的文章都差不多，无非是页面保持干净，内容不 要过多-—但也不是说不能比较多。另外，尽量少用甲乙丙丁一二三四这样 的结构，一个slide接着一个slide，就是一个问题接着一个问题，在slide上 直接、简明的说明问题，然后再以必要的元素阐释问题。

1 CLI

2 开发

3 杂项

3.1 如何编程获得一个module对象

3.2 如何定制Python Module的查找

3.3 如何定制Python Module的存储

名字写的这么绕，其实就是常用的struct initializer的写法{0}，老是这么 用，习焉不察矣，今天别人问起来。想起来差了老半天C/C++标准。终于把这 个问题搞清楚了。这里以C99标准为准–—C++标准的相关部分是从C标准里面 抄来的。

很显然，标准里面对不完全的initializer list的行为是有规定的，相关表述 如下(下面引文全部引自C99标准草稿):

[6.7.8.21] If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.

也就是说，类似这样:

struct {int a;int b;} aa = {0}; 

的写法是完全没问题的，并且会把a,b都zeroing(a是从initializer literal 来的，b是上述因为规定的)。

有一个基本常识是，C里面的非复合类型(我自己造的词，那么个意思，大家别 细究了)都可以用0初始化，所以{0}初始化上面例子中类似的结构是没问题的， 有的人的疑问在于如果struct的第一个元素是struct怎么办。标准规定了这种 情况下的行为:

[6.7.8.20] If the aggregate contains elements or members that are aggregates or unions, or if the first member of a union is an aggregate or union, these rules apply recursively to the subaggregates or contained unions. If the initializer of a subaggregate or contained union begins with a left brace, the initializers enclosed by that brace and its matching right brace initialize the elements or members of the subaggregate or the first member of the contained union. Otherwise, only enough initializers from the list are taken to account for the elements or members of the subaggregate or the first member of the contained union; any remaining initializers are left to initialize the next element or member of the aggregate of which the current subaggregate or contained union is a part.

这段话很长很绕，简单的说，如果aggregate(这里简单理解为struct，准确的 表述去看标准)的某个元素是aggregate,就按照普通的aggregate初始化规则找 到该aggregate的初始化列表开始的地方，如果是大括号扩着的，就用那个括 号里面的list初始化这个aggregate，否则就从这里开始找到"足够"的条目给 自己来initialize,剩下的给别人用。

以这个例子来说:

struct {struct {int a;int b;} aa;int c;} _a = {1 ,2}; 

struct的第一个元素是struct，initializer它相应的位置没有{…}这样的东 东，而是个"1"，那它就从这里拿"足够"的initializer来初始化自己，就是把 "1，2",拿来初始化a,b了。所以结果就是_a == {{1,2},0};

这样，对上面这个结构用{0}初始化就很容易理解了。