杨贵福 - Page 25 - 重剑无锋，大巧不工

以前能跑步的时候

我从来没有想到过，自己也会有这样的时候。想提某一个人名，明星之类的，半天想不起来，虽然他的事迹已经在心里

转了两三圈。明星们的名字和青春的脸，最后的一批，就是刘德华、关芝琳、林青霞、张学友他们，剩下的，都是新人

。以前记得的事情，就像刻下了一样，永远记住了；新近出现的人和事，也像是刻下了，只不过是刻在了将融化的巧克

力上，转瞬即逝。

但是我确实看到了时光的流逝。十年，不过弹指一挥。弹指一挥这样的词，古人诚不我欺。十年前的事情怎样一一发生

和推进，我还记得清清楚楚有如昨天，但是十年前的毛头小子都成熟得能教我讲政治了，而他们在我心里，仍然是十年

前的样子。这真令我感叹。

前几天半夜的时候去跑步了，跑了一千米左右，速度也不怎么快。但是中途的时候膝盖就开始疼，里面隐隐地有针在扎

，虽然能坚持，但是最让我担心的是我知道有些损伤是单向的，不可恢复。年轻的时候，以为只要努力，什么都能坚持

过去，以为大不了一死而已，却不知道其实死没那么容易，活着却是更难。当事已如此，还要眼睁睁看着它继续，是件

折磨人的事。

那天跟关同学提起膝盖疼的事，她说，像你这样的就不能再跑那么远了。我说，哪么远啊，那以前跑一千米是达标要求

，都得能跑下来，那能有多远。关同学一笑，说:老师，你跑一千米的时候是多大岁数的事了。

我只有呵呵。

不达到锻炼强度就抑郁，提高强度各个关节就开始声明自己的存在。这让我想起打帝国时代的时候，你缺黄金，也缺粮

食，也缺石头和木头，更糟糕的是，你还缺军事力量，因为敌人打来了。

非常怀念当年能跑的时候。我所谓的能跑，并非有多么快或者持久，而是如孙同学所说，"你们帝国时代打得水平实在

不怎么的，但是玩得挺乐。"

我记得早晨四五点钟，冬天，天还完全没有亮，呼出的白气能有一米多长，空气刺痛肺子。跑，只注意呼吸，也只能听

到自己的呼吸和脚步，上坡下坡，有远远的车灯射到雾里面。很快就会喘不过气来，然后坚持，再坚持，等脑袋上全是

汗的时候，呼吸也开始顺畅。我看到巨大的月亮向西山落去，就像晨雾后面隐隐透出光来的初升的太阳。我有点迷惑的

停下来看的时候，脸上有开始结冰一样的感觉，风呼呼地吹过耳包，眼镜上一片迷蒙。有人从我身边飞快地超过，大声

喊我跟上。他的步幅非常大，每步都像弓箭步一样，同时极有弹性，没有一丝拖泥带水。他穿着像衬衣那么薄的衣服，

大腿在踏地的时候有力抖动。事实上，他穿的是运动服，那个时候我还不太认识，或者说，在我看来二者的区别在那个

时代也不怎么明显。

我跟了一段，在一个上坡慢慢落后，然后眼睁睁看他消失在山坡另一面，就像船帆没入大海。其实，我还记得与他的简

短对话，但是内容并不重要，大致是:快跑啊，越快就越不累，诸如此类的。

之所以后回忆起这一位，以后再也没有见过，或者擦肩而过没几句对话，因为在冬天的早晨，在这样的灰色弯曲上升的

马路上，我几乎没有遇到过旅伴。大部分人还在酣睡，特别早起的是做豆腐的，他们两三点的时候已经开始工作。路上

行人极其稀少，我还见过几辆牛车马车，比遇到跑步的人还少。

而同是跑步的人，竟然没有一个与你的速度、路线和方向完全一致。所以到了一定的青春年岁才开始感慨孤独的孩子，

一定是没有在盘山路上晨跑的经历。天很黑，你很累，路很长。这让人如何不绝望。

那个时候，我兴冲冲地跑完，开始打一本钉在墙上的书。有几个手指节就是在那个时候偏向了一侧，紧握拳的时候并不

突出肌腱，击打的时候接触面以指骨为主。但是这从来也没有用在打架上，完全辜负了我年轻的期待。倒是我妈很有意

见，说打得墙咣咣的，让人睡不好觉。再就是那个时候指关节受伤，我姥把她辛苦养的像仙人掌那类的什么花送给我妈

，说这能治我的手。

那个时候，跑一圈下来累得要死。那个时候，没有想到有一天会怀念能跑的日子。我突然想起前两天看齐同学讨论

那么

多的抉择和苦闷的时候，我说，这些以后都是财富，是以后吹牛的资本，不然，到了年老的时候，拿什么出来吹，说我

当年很牛呢。

读赠卫八处士，听肖邦夜曲C小调第21。此时的夏夜，抬头当能看到浅淡的云，还有深蓝到泛黑的天空。佛陀感叹过人

生几苦，求不得，怨憎会，爱别离。也许，正是失去，也只有失去，才让我们感受到它清晰地存在。

人生苦短，世事无常，流沙过指隙。

对C语言的写文件操作fwrite的一个初学者常见误解

当初对C语言的写文件操作到底会有什么样的结果很困惑，今天读CSAPP的时候又把这段回忆勾起来了。以下，希望能对如当年我一样的同学们理解fwrite有点帮助。

1.题外话，文件的重要意义

教科书中一般都会提到C语言的文件有这么个特色，它把所有设备都看成相同的东西，并称这是个优势。有的同学可能会奇怪，这有什么可提的。这种优点是教科书的作者和教师们从更早的书里抄来的，更早的书是对当时的情况发表的看法。在UNIX系统和C语言以前，操作系统处于一个更萌芽和早期的状态，对不同的设备的操作都使用专门方法--你可以理解为各有单独的函数。试想，键盘、鼠标、显示器、打印机、磁带、磁盘、磁鼓，所有这些东西都要作读写操作，而读写操作从人类的视角看来如此之像，却使用全然不同的函数和参数。UNIX和C语言改变了这一点，它把所有的设备"抽象"为文件，对所有设备的操作，都用相同的一组函数，即文件读写，来完成。这些各种各样的文件当中，也包括目录，所以目录也是一种文件。网络socket也是一种文件，进程间通信，也是一种文件。当很多不同的东西都统一于文件的时候，它们的个性就抹杀掉了，容易管理和控制多了。

因为吾生也晚，咱们已经习惯于这个格局了，就认为用文件管理所有的东西是天经地义的事情了，所以难以感觉到诸侯割据各自为政时的不方便。

2.问题

当我们读文件的时候，事情相对简单。打开，然后读，然后关闭。我们读到的正是我们期待读到的东西。当我们写文件的时候，情况就不同了。

常见出现的错误是，我们可以有个文件，内容是：

abcdefghijlmn

我们的C代码是：

打开文件， (可能在中间某个位置) 写操作，关闭文件。

执行完C程序以后，我们发现文件的内容不是我们期待的结果。我们原本期待中间某处变成我们修改以后的样，比如：

abcAAfghijlmn。

但是文件的内容却变成了:

^@^@^@AA

3. 原因

造成上面的问题，其原因肯定不是"因为微软的编译器太垃圾了"，而是我们没有仔细阅读手册。

我们错误地假想，C语言操作文件流 (流，也是个UNIX语境下的重要概念)，就像操作内存里的数组一样，找开文件就是找到数组的头 (起始位置)，写操作就是改变数组中某处的元素。

但是事情并不是这样。世界并非如此简单。把文件作为流操作，那是文件打开以后的事情，在文件打开的时候，非常重要地，程序员必须指出，准备创建或打开一个什么样的流。

手册 (man fopen) 说:

fopen的第一个参数是文件名，第二个参数需要我们注意。第二个参数称为 mode，我们可以理解为创造的流的"模式"。

其中对"w"这种模式的解释的第一句是：

"Truncate file to zero length or create text file for writing."

truncate的意思是"截断"。上述这句可以译为：把文件截断为0长度，或者创造用于写操作的文本文件。这里插一句，在UNIX/POSIX系统下，文本文件与二进制文件没有区别。所以，"w"模式所创造的流是，要么如果原来这个名字的文件已经存在，把它截断为0字节，无论里面有什么内容；要么如果原来没有这个文件，创造一个新的文件。

前面问题一节里的文件，原本是：

abcdefghijlmn

我们期待：

abcAAfghijlmn

但是却变成了：

^@^@^@AA

1.AA以后的东西会丢失，就是因为原来的文件被trancate到了0长度. 2."^@"是单独一个字符，即''，这是由于我们的写操作是向某个特定位置进行造成的洞.

4. 解决

也许我们这些唯物主义者关注一下唯心的书，可能理解这个问题更容易一些。康德的《纯粹理性批判》、哈耶克的《科学的反革命》，还有 Design of Everyday Things，都提到一个观点。我们对于所有事物的理解和理解发以后的操作，都是基于心中的一个"模型"，或者说，我们认为它会 (或者应该) 那样工作。

如果它不是那样工作的，我们会说建模有问题。不过这个字眼很学术味。它的意思大致等同于，那玩意根本就不是你想的那么回事。对于fwritet这个具体问题而言，它不是如我们误以为的数组这样的流，而是在fopen时决定了，会对文件系统有些副作用的操作，然后创造了流中的某一种。

我们想要的效果，需要用以下方法解决.

FILE * f = fopen ("test.in", "r+");

// 注意此处不是 FILE * f = fopen ("test.in", "w");

// w模式会把文件内容清空

// r+这种模式的意思是：

// Open for reading and writing. The stream is positioned at the beginning of the file.

5. 补充个无关的，sizeof

char output[3] = "AA"; /* sizeof -> 3, the number of the array elements */

对数组sizeof操作 (其实sizeof不是函数，而是关键字)，得到的是数级中元素的个数.

char* output = "AA"; /* sizeof -> 4, the size of pointer type */ */

对指针sizeof操作，得到的是指针这一数据类型 (不是指针的基类型)的长度，指针在32位系统中是4字节。

6. 代码

6.1 覆盖文件内容的写操作

test.in的文件内容：

abcdefghijk

执行结果为：

^@^@^@AA

或者十六进制形式为：

$ hexdump -C test.in

00000000 00 00 00 41 41 |...AA|

00000005

C代码：

#include <stdio.h>

int main(int argc, char *argv[])

{

char output[] = "AA";

//FILE * f = fopen ("test.in", "r+");

FILE * f = fopen ("test.in", "w");

fseek(f, 3, SEEK_SET);

fwrite(output, sizeof (output)-1, 1, f);

fclose (f);

return 0;

}

6.2 替换文件内容的写操作

test.in的文件内容：

abcdefghijk

执行结果为：

abAAefghijk

C代码：

#include <stdio.h>

int main(int argc, char *argv[])

{

char output[] = "AA";

FILE * f = fopen ("test.in", "r+");

//FILE * f = fopen ("test.in", "w");

fseek(f, 3, SEEK_SET);

fwrite(output, sizeof (output)-1, 1, f);

fclose (f);

return 0;

}

7. 致谢

想起当年从BASIC语言向C语言迁移时，师兄们的教导令我受益良多。感谢张仕鹏师兄，还有一位一时名字没想起来的师兄，还有于寅虎师兄。恩，还有灌我酒的唐猛师兄，通过TC的BGI教会了我指针。

--------------------

博客会手工同步到以下地址：

[http://giftdotyoung.blogspot.com]

[http://blog.csdn.net/younggift]

用windows sdk写一个贪吃蛇

这是上学期程序设计与实践3课程的一部分，用windows sdk写一个贪吃蛇。此项目由教师在课堂上演示、查SDK手册和解释、design和实现及解释代码，学生观摩。一共进行了五次课。持续五周，每周一次课，每次课90分钟。

1. 原由

之所以选用 windows sdk的原因如下。1.我的学生刚好学了一部分 windows sdk，虽然sdk更难，但是对于我的学生来说，比MFC却要简单。原因很明显，因为MFC无论有多么好，他们没学过。同理，.net也不如sdk适合。有的时候用户需求就是这样诡异，而你只能随着用户的知识结构调整自己，而不是反过来。2.java awt/swing同学们倒是学过，但是大家以后用java做gui的机会比较少。3.虽然不少人以后可能会做前端，但是用java script之类的也不合适，理由也是他们没学过。教师不能把所有的课程都变成补基础知识的课程。只能因陋就简了。

选sdk的另方面的原因是希望通过贪吃蛇训练学生：1.即使没有学过某种知识(比如画图、音乐、刷新GDI等等)，仍然能通过查手册建立技术原型；2.了解消息循环。

没有学习过，但是却可以自学，是一项重要的能力。假期的时候王师兄提到他遇到的一位女导师，似乎是用GTK从VC移植界面，花了两个 (？)小时就完成了。问她以前学过吗，她答：没，看看手册，然后就做出来了。我们希望培训学生这样的能力。我得承认，这很难，对教师比学生还要难。所以此贴谨供有此理想的教师和同学参考，并热烈期待指导和意见，而此贴本身绝非指导意见。

2. 流程

一般的软件工程 (和/或示范)都假设同学 (或工程师)已经具备和掌握了相关技术知识，对于底层机制的调用是routine类的工作。在本案例中，由于同学们对sdk能做些什么尚无完善的认识，因此大体的流程与通常的软件工程有所不同。我们先做简单的需求分析，估计有哪些功能是我们需要的，然后通过google和手册到sdk中找，找到了以后要做实验，证明这个功能是我们可以实现的，最后再把这些功能的代码在最后要用的项目中写一次。

这有点类似于快速原型法，但是动机不同。快速原型法的目的是确保软件工程师对用户的需求理解无误，用呈现出来的方式与用户确认。我们做原型的目的，是确保SDK这样的底层机制确实支持你要使用的功能。这对于初学者或者探索类的项目具有格外重要的意义。

3. 技术原型

把在需求非常粗糙的时候，先写出来的一些小程序，用于验证底层机制 (如SDK)支持这样的功能，这种小程序我们估且称为技术原型。

在课堂上，我们认为贪吃蛇有以下这样几个技术原型需要确认。

(1)画一些线，组成矩形； (2)把矩形擦掉； (3)把擦和重画结合起来，形成动画效果； (4)不阻塞地获取按键的状态，即程序不停，而在按键时做出某种影响。

前三种技术原型在写程序之前，先有"手动"的演示。教师在画图工具上，画出矩形，然后擦、画，形成动画效果，同时简单介绍视觉暂留现象。

按键获取这一技术原型，教师指出 getchar 或 scanf 这一类的函数不适合的原因，然后引入消息循环的概念。

4. 技术原型的补充

在开发的过程中，又发现需要 timer 的技术原型。把主项目停下来，写 timer技术原型，验证之后，把代码复制和修改到主项目中。

在开发中，发现当初考虑得不周到，有未尽的技术原型，这是正常的现象。除非你正完成的是与既有工作没大差别的项目，未计划周全是正常的。这也是教师在课堂写程序同时学生观摩的意义之一，使学生认识到"错误"不可避免，同时重要的是遇到"错误"如何修正。教师在课前把代码写好调好，课堂上按下F5就运行，同学们无法看到教师修正错误的过程，而这一过程会是他们写下最初100行时最需要的经验。

5. 对技术原型的再讨论

每个原型都在200行左右，除去由wizard生成的消息循环代码，就更短了。这在学生注意力和理解力可达的范围内。如果以整个工程的面目示人，则学生就需要从大的背景中找出某种技术对应的代码来，这就难多了，学生更容易产生挫败感。

每个原型都比较短，即使加上教师课堂上解释的时间，读文档的时间，一般地一到半次到两次课也能够完成。从无到有，虽然只是实现了一个小功能，但是如果学生事先就知道这一功能将出现在最后的工程中，这点小成就还是可以让他们小小地满足一下。

这些原型除了课堂演示，还要求同学们作为作业在当周完成。观摩教师写代码，和自己亲手历经各种困难把自己在课堂上已经见到效果的小项目重现出来，课程实践表明，难度上还是有很大差距的。事实上，全程能基本跟下来所有原型实验的同学，只有一名。

另，把技术原型中的代码抄到主工程中的时候，教师强调业务逻辑与技术原型的分离。业务逻辑是尽可能与所依赖的平台和技术原型无关的。当然，类似于消息循环和按键消息响应这一类的技术原型，不可避免地与框架相关联。好在，这样的技术已经可以在相当程度上视为通用技术了，在很多平台上都类似。

6. 抽象

利用原型已经验证过的那些api，代码半抄半改，形成了整个贪吃蛇项目。当程序能跑起来没有bug的时候，同学们非常兴奋。我记得当时大家还鼓掌喊"oh yeah"了。

对于软件工程想要贯彻地教学目标而言，这才只是开始，如何抽象，比如用面向对象，比如把重构extract函数，这些才是真正的动机。而这些内容的教学，可以建立在上述刚刚由大家一起完成的贪吃蛇项目中。

在课堂中，我提出"需求变更"，蛇头的颜色要求不同，碰撞的规则的变更，要求有更多的关卡等等。有些需求变更的满足，演示了extract函数，比如蛇头的颜色；有些要求重新设计数据结构 (结构体) ，变修改访问过这些结构体的函数；要求更多关卡这个，则演示了DSL的代码生成技术，我们又写了一个程序，专门用于把ASCII艺术画方式实现的关卡地图转换为C代码。比如下面几个关卡中，用"*"代表有障碍物的地方，"."代表空白处：

......

......*

.....**

......*

.....***

------------------------------------

....*******

..........*

....*******

....*

....*******

-----------------------------------

....*******

..........*

....*******

..........*

....*******

-----------------------------------

....*.....*

....*.....*.

....*******

..........*

-----------------------------------

....*******

....*.....

....*******

..........*

....*******

上述关卡会由代码生成器转换成这样的代码：

#define MAX_BLOCK_LENGTH 100

int block_length_stage[5] = {0, 10,23,23,13 };

int block_x_stage[5][MAX_BLOCK_LENGTH]={{0},

{6, 5, 6, 6, 6, 6, 6, 5, 6, 7},

{4, 5, 6, 7, 8, 9, 10, 10, 4, 5, 6, 7, 8, 9, 10, 4, 4, 5, 6, 7, 8, 9, 10},

{4, 5, 6, 7, 8, 9, 10, 10, 4, 5, 6, 7, 8, 9, 10, 10, 4, 5, 6, 7, 8, 9, 10},

{4, 10, 4, 10, 4, 5, 6, 7, 8, 9, 10, 10, 10}

};

int block_y_stage[5][MAX_BLOCK_LENGTH]={{0},

{3, 4, 4, 5, 6, 7, 8, 9, 9, 9},

{4, 4, 4, 4, 4, 4, 4, 5, 6, 6, 6, 6, 6, 6, 6, 7, 8, 8, 8, 8, 8, 8, 8},

{4, 4, 5, 5, 6, 6, 6, 6, 6, 6, 6, 7, 8}

};

关卡生成器也放在了附件中。

7. 未尽之事

最后的结果并非漂亮的设计，课堂中我也提到，真正的工程一般不会给我们机会做这么多地技术原型--它表明工程师的技术仍不成熟。但是，技术不成熟如果是事实的话，那么事实只能通过弥补来减弱影响，而不可能通过掩盖来避免负面效果。所以，如果学生或工程师技术不成熟，技术原型是一个帮助的工具。我们不能因为工具会暴露人类在体力上相对其他动物不足而拒绝使用。

代码也并非漂亮的代码，事实上，有很多不尽人意的地方。这些地方未进行修改的原因，一是我作为教师确实能力有限，对SDK的了解远不全面和深刻，二是它们超出了我原定的教学目的。

8. 感谢

我上课的时候犯了一个错误，没有先建立版本控制就开始写代码，每次课后备份的时候都覆盖了前次的代码。最后的结果固然还在，但是中间的过程也是我希望呈现的，不可或缺。

好在尤其同学备份了每次的代码，并非未如我一般愚蠢地操作，所以中间过程得以保留。所不完满者，尤其同学只备份了代码，而非整个工程，虽然保留了核心的代码，但是需要一些VC的使用知识才能编译。

9. 附件的目录树

|-- draw 绘制矩形的技术原型

|-- erase 擦除矩形的技术原型

|-- keyup 按键检测的技术原型

|-- from_YOUQI 尤其同学给出的有版本控制的代码

| |-- week10

| | |-- draw

| | `-- erase

| |-- week11

| | |-- keyup

| | `-- snake

| |-- week12

| | |-- snak_business_logic_imp.h

| | `-- snake.cpp

| |-- week13

| | |-- snak_business_logic_imp.h

| | `-- snake.cpp

| `-- week14

| |-- gamedesigner.cpp

| |-- run.bat

| |-- snak_business_logic_imp.h

| |-- snake.cpp

| `-- stage.txt

`-- snake

|-- gamedesigner 关卡生成器

| |-- Debug

| | |-- run.bat 脚本/批处理，用于把stage.txt转换为stage.h

| | `-- stage.txt 关卡定义的源文件，关卡生成器的源文件

|-- snake

| |-- snak_business_logic_imp.h 业务逻辑

| |-- snake.cpp 消息循环框架

| |-- stage.h 关卡生成器的输出文件

我无法通过GFW，因此不能向blogspot传附件，请参见[http://download.csdn.net/detail/younggift/6029671]

--------------------

博客会手工同步到以下地址：

[http://giftdotyoung.blogspot.com]

[http://blog.csdn.net/younggift]

今天暑假我做了什么

今天暑假是我从初中二年级开始，唯一算得上假期的一个夏天。初二开始，假期不是各种学校要求的补习，就是竞赛，反正没有消停时候，连初中毕业、高中毕业、大学毕业后的假期也没歇着。今年假期算是例外了。

暑假原计划去趟通化老家，再跟好朋友去旅游一下。结果，刚放假，老猫就病了。它屁股上长了青春痘一类的东西 (学名肛门腺) ，烂了个洞，得天天上药。所以人类也无法远行。我本以为这是给猫上刑，结果猫妈准备了老猫酷爱的妙鲜包，每天上刑的时候老猫都屁颠屁颠地往前凑。

即然走不了，就只好读书。暑假在继续读没看完的几本，有进度的包括：CSAPP，实时系统，历史理性的重建，Algorithmic Adventures，On Lisp, The Design of Everyday things。及一些乱七八糟的东西。以上都没看完。

另一个重要收获是假期快结束的时候开始打星际争霸任务。星际争霸是1998年的老游戏，那个时候windows2000也还没出世，更不用说xp。显示器那时都是4:3的，所以这款老游戏不支持宽屏，得先调成窄屏然后才能玩。插话评论一下，我一直震惊于有些人在宽屏上看普屏的电视节目，人压缩得矮胖，但是他们还是能看下去。星际争霸似乎是640*480的如此之低的分辨率，更不用说好象还是16分游戏，不是16位，而是16种颜色。平衡性什么的，这么有名气的事情，我就不赘述了。任务的故事性挺强，如看美国大片。欺骗与背叛，情理和公义，隐约的爱情，古老家族 (或者贵族？)的腐烂，你能想到的基本都有。更难得的是身在其间，感觉格外不同。

这游戏给我最大的启发是：如果需要训练什么技能，一定要尽早。这道理我最初是在李笑来先生的《把时间当作朋友》里看到的。他说，如果很早就会五笔的话，一定能比别人多记很多笔记；如果很早学会快速阅读，一定能比别人多读很多书。大致如此，不是原意，李笑来先生反对五笔和快速阅读这种东西。我的体会，如果发展徒手攻击力需要100矿+100气的话，那么升级比生产同样价格的兵要有价值得多。因为它会使你手头所有的兵及今后的兵都是更有价值的。

唯一需要考虑的前提就是，如果当前能活下去。所以，只要现在还能对付活下去，那么，发展未来远比现在重要。我们活在未来，而不是此刻。

不那么幸运的就是在星际争霸里，正打得顺风顺水，突然被翻盘的可能性太大了。敌人会根据你的兵种情况生产克星。所以，经常性地了解对手的发展情况，对我们来说也非常重要。

再就是，有些任务的关卡实在太难打了，简直不是人类能通过的。可能一，咱们技艺就是不行。虫族最后一关，我要花近两个小时，而网上录像我看到十几分钟推平敌人的，有的是。可能二，任务的目标根本不是打平天下，而是在一片战火中送个人到什么地方去--这相对容易多了。所以，充分了解用户需求是多么地重要啊。

暑假最重要的收获，我真正地成为了物理系毕业的学生。不是指同学聚会，我终于能用筷子起开啤酒了。这是所有物理男的必修课，今夏补考通过。有窍门，以后再讲给你们听。

这个奢侈地暑假，你做了些什么？

--------------------

博客会手工同步到以下地址：

[http://giftdotyoung.blogspot.com]

[http://blog.csdn.net/younggift]

同学聚会

今天假期的一件大事，就是大学同学要聚会，早早就把时间定下来，别的事情都为聚会让路。

我们年级一共95多人，此次回来50多个，大家在一起吃睡玩了几天。作息一致，就是大学时的感觉吧。有些同学已经叫不出名字了，有的同学干脆就完全没有印象。大多数同学，基本没有什么变化。也许变老了些，性格上基本都是以前的强化或者加些世俗的因素。

一般都问问职业。不少人从事IT相关的行业。我第一次听到这个词还愣了一下。IT，这是当年还没有的词汇。15年来，产生了不少新词，世界变化真大啊。

我原以为15年来自己成长成熟了很多，兴冲冲地准备向大家汇报。结果大家说的话里的机锋，我仍然得别人背地里解释了才能明白。显然，我虽然进步了，但是仍然跟不上大家的脚步。

2013夏天似乎是聚会高峰，我听说地看到的不少大小聚会。也许，2012过完了，我们终于认识到仍然活着该有多么宝贵。所以得聚聚了，以示珍惜。

在我们去物理系认养松树那天，我早到了，看到门口挂的条幅写着89级同学聚会。我想，系里这也太不靠谱了，核计着找谁联系换一下。正想着，从门里哗啦啦出来一批老头老太太 (和我的同学比)。原来，真的是89级同学在聚会。后来在东师会馆等同学，一位男士径直走到我面前热烈握手，自报家门说他是谁谁谁。我说：师兄你好，我不是你们那届的。

今天夏天，还有师兄回来长春，我跟着师兄的同学 (我的师兄们及宝贵的师姐1人) 聚了一次，又单独谈了两个下午。他给我讲了科学问题是什么意思，我收获很大。

--------------------

博客会手工同步到以下地址：

[http://giftdotyoung.blogspot.com]

[http://blog.csdn.net/younggift]

解密：LL与LR解析 2（译，完结）

由于GFW，我无法联系到作者，所以没有授权，瞎翻译的。原文在这里[http://blog.reverberate.org/2013/07/ll-and-lr-parsing-demystified.html]。
这是第2部分和完结。 3. 解析树的形状
到目前为止，我们使用的算术表达式的那棵树，仍然不是解析树，因为它并未与语法关联。要考查一棵真正的解析树，我们需要语法。不幸的是，为中缀算术表达式写语法不像你期待的那么简单和优雅。对优先级和结合性 (杨注：操作符左结合还是右结合)编码，保证语法没有二义性 (并受LL和LR支持) ，是非常丑陋和不符合直觉的。这也是为什么LL和LR解析器也允许你做指定操作符优先级这样的扩展；比如，参见Bison优先级的相关特性[http://www.gnu.org/software/bison/manual/html_node/Precedence.html#Precedence]。而这篇文章的目的是打算讨论纯的LL和LR。

因此，我们得把那个算术表达式的例子调整为比较容易写的语法的形式。我们将使用JSON (杨注：JSON是javascript的对象表示方法) ，既然它非常简单，而又足够复杂和有趣。

1 object → '{' pairs '}'
2
3 pairs → pair pairs_tail | ε
4 pair → STRING ':' value
5 pairs_tail → ',' pairs | ε
6
7 value → STRING | NUMBER | 'true' | 'false' | 'null' | object | array
8 array → '[' elements ']'
9
10 elements → value elements_tail | ε
11 elements_tail → ',' elements | ε

上面，我用了单引号括起的字符串表示原文文字标记 (literal tokens)，用大写字母，比如STRING，表示那些拼写不确定的tokens (比如，"abc"和""都是有效的STRING tokens)。所有的名字小写字母的，都是语法规则 (也称非叶节点)。

你可能奇怪，为什么我要用 pairs_tail 和 elements_tail，而不用重复构造 (repetition construct) ，像很多解析器比如ANTLR支持的那样。这样，我们就可以这样写：

elements → value (',' value)*

使用*的这种语法，用起来更方便，语法也更简单，但是同时，它导致解析树概念上更复杂了一点，因为某个给定的语法规则的子树个数不再是确定不变的。并且，LR解析器不支持重复操作符(比如，Bison就不支持)，这样，我上面写的语法就既可以用于LL也可以用于LR解析器。因此，我们现在要使用这个有点复杂的语法。

现在，我们有语法了，那么我们来看一个token的流的例子，再来看输出的解析树。

{"message":"Hello, World!"}

上述这段文字的token流是：

{ STRING : STRING }

而它的解析树，按我们的语法，就是：

注意，所有的叶结点 (绿色的)都是tokens，它们的顺序与我们的解析器的输入顺序是完全一致的。 (我做了一点小弊，把ε作为叶结点了，不过正如我们所看到的，这看起来更干净更规则一些)

我前面曾经断言过，LL解析器输出的是先序遍历，而LR解析器输出的是后序遍历。从这一点出发，我们可以知道LL和LR解析器对上述输入分别会给出什么输出：

既然叶节点总是输入的tokens本身，且完全按输入的顺序，所以所有的解析器真正所做的，就是把中间节点 (杨注：语法规则)插入到合适的位置。看这一点的另一个角度就是，一棵解析树，就是一堆结构体，这堆结构体定义在输入的tokens的序列之上。我们稍微重新安排一下之前的这个图示，这一点看起来就更清楚了。

我们正集中讨论一个非常简单的模型，用这个模型描述LL和LR解析器如何工作。LL和LR解析器二者都读入一个输入tokens的流，再把相同的流作为输出，并且把规则 (杨注：中间节点)插入到适当的位置，以形成解析树的先序 (LL)或后序 (LR)遍历。

这样，按波兰和逆波兰表示法考虑，这种对解析器输出的认识又带给我们一个好处。它使得我们可以对解析器的输入和输出都按简单的、平坦的流建模。这比把解析器的中间输出状态视为部分地构造树要容易多了，那种思路对于理解输出和对输出的检验都没什么帮助。

4. 超前 (Lookahead)

LL和LR解析器都是"在线的"，意味着它们都能在输入正在进行时开始产生输出. 但是在许多情况下，在流的位置之前的tokens没有包含足够的信息，因此解析无法知道是否需要插入规则 (或者，如果需要插入规则，应该插入哪一条).因此，解析器得超前 (lookahead)到流的后面，看看下面的一些tokens是什么，以便做出决定。当你看到像LL(1)或者LR (0)这样的命令的时候，括号里的数字就是要超前的tokens的数量。

值得注意的是，超前是相对于规则将要插入的位置而言的，这个位置 (正如你记得的)对于LL解析器而言是在规则的tokens之前，而在LR解析器的规则tokens之后。这意味着，LL超前从规则的tokens的开头开始计数，LR从末尾开始计数。这带给LR解析器一个巨大的益处，因为在它们做出决定之前，他们能够看到规则的所有tokens (可能再超前一些)，而LL解析器只能看到规则最初的几个tokens。

这就是为什么会有LR(0)解析器这种东西，而LL(0)解析器是不可能存在的；那样就根本不会有信息用来帮助决定接下来的tokens应该使用哪条规则。

5. 结果

根据上述对于LL和LR解析的比较的理解，我们能够得到几条重要的结论，有助于理解为什么有些当然的事是那样的。

(1) LR解析器能够处理更多的语法

这一点可由上一节超前 (lookahead)推得。既然LR超前开始于规则的末尾，在做决定的时候，LR(1)就确定地比LL(1)拥有更多的信息。进而，LR(1) 解析器确定地能比LL(1)解析器多解析一些语法 (杨注：原文接下来在括号里是modulo LL-only grammar extensions; see below。我不知道什么意思)。LR解析器可以处理左递归，LL解析器不能。

优势：LR

(2) (杨注：EBNF这一类的)

另一方面，既然LL解析器在开始解析规则的tokens之前就选定了使用哪条规则，并且无论LL解析器什么时候解析一个token的时候，它一定知道其token的上下文。这是一个更困难的任务 (既然它们拥有的能够继续的信息更少)，这导致了一些重要的优势。

LL解析器在语法中能支持像正则表达式一样的操作符。

知道解析的上下文，这使得利用正则表达式形式的多种多样的操作符成为可能，比如重复 (杨注：*)，比如alternation (杨注：|)，而且可以用在任何地方，而不仅仅是顶层处。基本上，每条规则都能构成一个DFA状态机。对于自顶向下的解析，这是可能的，因为解析器知道它位于哪条规则之中，在解析进行的过程中可以按规则的状态机进行。我认为这对于自底向上的解析，这是不可能的 (甚至如果你以某种方法令解析表做正确的事，归约那一步也需要归约有固定不变的参数个数。杨注：不懂)。这对于LL真是个好优点，因为有这些丰富的语法扩展(杨注：指类似正则表达式的)，语法容易读多了。事实上，这有利于使LL那种严格语法的局面有所缓和，因为许多你需要左递归的地方都可以使用重复 (*)操作符替代。

1 // LR语法: 不允许任何特殊的，alternation 只允许
2 // 在顶层出现
3 //
4 // 允许这一条是因为它等价于
5 // pairs → pair pairs_tail
6 // pairs → ε
7 pairs → pair pairs_tail | ε
8
9 // 扩展的LL语法；之所以可能，是因为你可以对把每条规则
10 // 构造成一个DFA
11 pairs → (pair (',' pair)*)?

后一条规则可以构造出像这样的DFA (绿色的状态表示接受状态) ：

知道上下文，也使得在规则中间的动作成为可能 (定制代码，这些代码运行在规则里的任意两个元素之间。杨注：如antlr的 semantic action)。Bison支持这一点，是通过在内部重写了语法，这使得所有的可视化 (杨注：可能指语法定义的时候？)都更加复杂了。

优势：LL

(3) LL解析器支持上下文相关的扫描/词法分析

知道上下文，另一个好处是也使得上下文相关的扫描/词法分析成为可能。比如，许多程序设计语言不允许把关键词用于变量名，因为独立的词法分析器 (及自底向上的解析器)不知道出现在这个位置上的token是变量名还是关键字。但是自顶向下的解析器调用词法解析器的时候，可以轻易地把当前的上下文传递给它。

优势：LL

(4) LL解析器支持继承属性

知道上下文，也能够支持基于LL的应用程序在构造树的时候把属性/元数据传递给树 (这有时被称为继承属性。杨注原文：inherited attribute)。 (无论LL还是LR解析器都支持综合属性 (杨注：原文synthesized attributes)，是由树向上传递的)。

优势：LL

6. 结论

我描述了一种另类的LL和LR解析器的模型，这种模型与大多数文献中提到的等价，但是更符合直觉 (至少对我而言是这样)。我们可以把解析器视为黑盒子，这个黑盒子输入输出与先序和后序表示法对应的token和规则的流。至目前为止，我们还没有探索这些解析器的内部工作原理；我们只是把它们视作黑盒，我们不清楚它们内部的工作。我们也没有探究它们能处理和不能处理何种语法的问题。我们也没有探索LL和LR的变形 (Strong-LL, SLR, LALR等等)。我希望在接下来的文章中会更完整地讨论它们，再包含上示例代码。

解密：LL与LR解析 1

解密：LL与LR解析

作者：Josh Haberman翻译：杨贵福

由于GFW，我无法联系到作者，所以没有授权，瞎翻译的。原文在这里[http://blog.reverberate.org/2013/07/ll-and-lr-parsing-demystified.html]。

2013年7月22日

我最初解析理论的经历来自大学时自学程序设计语言的时候。当我学到像LL，LR还有它们的变型 (比如Strong-LL, SLR, LALR等等)的时候，我迷惑了。我觉得正注视着的是艰深而强大的咒语，它的重要意义我尚不能领会，但是我确信，总有一天，像"从左至右导出""最右导出"这些术语会融汇贯通，于是我继续努力期待明白的一天。

现在我可以说，经过10年的时间再加上看了一整架解析类的书以后，我把这些算法理解得不错了。但是我看待它们的角度和我看过的文献都非常不同。我更多地从实现的角度，而不是数学的角度，数学的角度也起了一些作用 (杨注：瞎翻译的)。无论如何，我想解释一下我是如何看待这些算法的，希望有人也像我一样觉得这个角度更直观。

这篇文章只涉及到把解析器视为黑盒子这一角度：即解析器的输入/输出，及解析器的限制。后续的文章将打开黑盒子，把这些算法内部工作的更多的细节展示出来。

1. 解析与波兰表式法

如果你在大学学习计算机科学，或者甚至你要是有个惠普的计算器 (杨注：我从来没见过逆波兰的HP计算器，而且，空格在那上面如何表示啊？) ，你就见过波兰和逆波兰表示法。它们能不用符号，也不用四则运算顺序规则，就能写出数学运算表达式。我们习惯于把表达式写作中缀形式，在这种形式下，操作符置于操作数二者之间：

1 + 2 * 3

在这种形式下，你如何知道计算的优先级呢？你不得不按约定的规则 (四则混合运算的法则)。你如何想按不同的次邓，就必须用括号了，像这样：

1 (1 + 2) * 3

在波兰和逆波兰表示法中，你不必关心四则运算的优先级，也不必加括号，同样可以避免二义性。这是通过把操作符放在操作数之前(波兰表示法)或之后 (逆波兰表示法)实现的。它们也分别被称为前缀和后缀表示法。

// 第一个例子: 1 + 2 * 3 // 中缀+ 1 * 2 3 // 波兰表示法 (前缀) 1 2 3 * + // 逆波兰表示法 (后缀)

// 第二个例子： (1 + 2) * 3 // 中缀* + 1 2 3 // 波兰表示法 (前缀) 1 2 + 3 * // 逆波兰表示法 (后缀)

除了不需要括号，也不需要运算次序的约定以外，波兰和逆波兰表示法在写运算器 (求值)的时候也容易很多 (也许HP计算器的设计师用逆波兰表示法，就是为了能去巴哈马群岛度一周假) 。下面是一个Python实现的逆波兰的简单求值器。

1 # 函数定义了操作符，及如何依据操作符求值
2 # 本例假设操作符都是二值的，不过容易扩展为多值。
3 ops = {
4 "+": (lambda a, b: a + b),
5 "-": (lambda a, b: a - b)
6 }
7
8 def eval(tokens):
9 stack = []
10
11 for token in tokens:
12 if token in ops:
13 arg2 = stack.pop()
14 arg1 = stack.pop()
15 result = ops[token](arg1, arg2)
16 stack.append(result)
17 else:
18 stack.append(int(token))
19
20 return stack.pop()
21
22 print "Result:", eval("7 2 3 + -".split())

波兰和逆波兰表示法，确实如通常所说的，需要事先知道所有操作符的参数数量。这里的参数数量，指的是操作符所作用的操作数的数量。这意味着，单值操作符负号和二值操作符减法，是两个不同的操作符。否则，我们在遇到操作符的时候，就不知道从栈中弹出多少个操作数。

一种避免了这个问题的类似表达方法，是Lisp语言的s-表达式。s-表达式 (还有类似的编码形式，比如XML)避免了固定操作符参数个数的需要，实现这一效果的方法是明确标记每个表达式的开始和结束之处。

1 ; Lisp风格的前缀表达式；
2 ; 同一个操作符可以有不同的参数数量
3 (+ 1 2)
4 (+ 1 2 3 4 5)
5
6 ; 我们前两个例子在Lisp中的等价表达方式
7 ; 前缀: + 1 * 2 3
8 (+ 1 (* 2 3))
9
10 ; 前缀: * + 1 2 3
11 (* (+ 1 2) 3)

Lisp这一表达法有不同于前述方法的妥协 (前面的方法中要使用固定数量的参数，Lisp需要括号)，但是它们底层的解析/处理算法是非常类似的，因此通常我们把它们视为略有不同的前缀表达式。

看起来我好像有点跑题了，不过，其实我一直在偷偷地讨论LL和LR。按我的观点，LL和LR解析正分别与波兰和逆波兰表示法直接相关。不过为了完整地探索这个想法，我们需要先描述一下我们需要解析器输出什么。

作为一个有趣的练习，请尝试实现一个算法，用于把波兰表达式转化为逆波兰表达式。看看你是否可以不需要先把整个表式式转化为为一棵树；你可以只用一个栈实现这个效果。现在，比如你又要实现相反的过程 (从逆波兰到波兰)--你只需在输入上运行同一个算法，这回转换的方向就相反了。当然，你也可以构造一棵中间的树，但是这导致 O(输入长度) 的空间，而单使用一个栈的解决方案只需要 O(树的深度) 的空间。如何从中缀到后缀呢？有一个非常聪明和高效的算法，称为调度场算法[http://en.wikipedia.org/wiki/Shunting-yard_algorithm]。

2. 解析器及输出

我们一致认可解析器的输入是token的一个流 (这个流极可能来自一个词法分析器，不过我们可以以后再讨论这一部分)。不过解析器的输出是什么？你可能倾向于说"一棵解析树"。当然你可以用解析器构造出一棵解析树，不过也可能不是这样，而是一种完全不构造解析树的输出。比如，这个Bison的例子[http://www.gnu.org/software/bison/manual/html_node/Infix-Calc.html#Infix-Calc] ，在解析的同时求值了算术表达式。每次当子表达式被识别出来，它立即被求值，直到最终的结果是一个单独的数。从来没有解析树显式地构造出来。

因此，说解析器的输出是一棵解析树不具有足够的一般性。相反地，我断言：解析器的输出，至少我们今天讨论的LL和LR的输出，是解析树的 *遍历*。

如果触动了哪位真理洁癖的神经，我在此道歉。我可以听到有人抗议道，树的遍历是一种算法，是你施加于一棵树上的操作。我怎么能说解析器输出了一棵树的遍历呢？答案在于，请回想一下刚才的波兰和逆波兰表式法。它们通常只是一种数学算式的表示法，不过我们也可以更一般性地把它们视为对树的遍历的扁平和线性的 (序列化的)编码方式。

回想下我们的第一个例子 1 + 2 * 3。下面是这个表达式的树形的写法：

+
/
1 *
/
2 3

有三种方法遍历这个二叉树，如在维基百科上所给出的：中序遍历 (in-order) ，先序遍历 (pre-order) ，后序遍历 (post-order)。它们的不同只在于你访问父节点的时机，是在访问子节点之前 (先序)，之后 (后序)，或者左右子树之间(中序)。这三者正与中缀、波兰、逆波兰表示法对应。

1 + 2 * 3 // 中缀表达式，中序遍历+ 1 * 2 3 // 波兰 (前缀)表达式，先序遍历1 2 3 * + // 逆波兰 (后缀)表达式，后序遍历

所以，波兰和逆波兰表示法完全地编码了一棵树结构，并且规定了你遍历它的步骤。在这些编码方法与一棵实际的解析树之间的主要区别，在于波兰和逆波兰表示法编码的访问并非随机的。对于一棵真实的树 (杨注：计算机里的真实，不是现实的真实，哈哈，所谓真实)，你可以跟随一个内部节点到它的右子树，或者它的左子树，或者甚至 (对于许多树而言)它的父节点。在这些线性的编码方案中，就没有这种灵活性：你只能采用它已经这样编码了的那种遍历方法。

但是，好的一方面是，它使用解析树的输出是一个流，这个流是在解析行为发生的时候产生的。这也是Bison的那个例子，它如何在没有实现构造一棵树的情况下，就能够求值算术表达式。如果真的需要一棵不是扁平编码的树的话，从线性的树遍历中很容易就能构造出一棵来。不过，当不需要这棵真的树的话，构造它的代价就完全可以避免。

这就引出了关键点：

LL和LR解析器操作之主要不同在于，LL解析器输出解析树的先序遍历，而LR解析器输出后序遍历。

这等价于那些更传统，但是 (按我的观点)更易令人迷惑和不那么直观的关于区别的解释：

* "LL解析器产生一个最左导出，而LR解析器产生一个逆转最右导出。"

* "LL解析器自顶向下把树构造出来，而LR解析器自底向上构造。"

* LL解析器通常称为"带预测的解析器"(杨注：原文predictive parsers，这是不是有约定的翻译啊)，而LR解析器称为归约解析器 (杨注：原文shift-reduce )。

今天先翻译到这里，原文后面还有。

昨天CSAPP上的疑问的解答

今天整明白了。

CSAPP英文版第2版，826页，或者中文版第2版546页，有这么一段。关于多级页表的。

"But if we had a 32-bit address space, 4KB pages, and a 4-byte

PTE[page table entry, 杨注], then we would need a 4MB page table

resident in memory at all time..."

其中"32-bit address space"的意思是 2^32 bytes，而不是2^32 bits，因为内存是按字节而不是按比特寻址的。

根据公式：页表尺寸 = (地址空间 / 页尺寸) * PTE入口大小........公式1

32-bit address space: 2^32 bytes (昨天误作bits)

4KB pages: 4K bytes

a 4-byte: 4 bytes

B: bytes

又

K = 2^10

M = 2^22

代入公式1的右侧，得

(2^32 bytes / 4K bytes) * 4 bytes

= 2^32 * 2^2 / (2^2 * 2^10) bytes

= 2^22 bytes

= 2^2 M bytes

= 4MB

--------------------

博客会手工同步到以下地址：

[http://giftdotyoung.blogspot.com]

[http://blog.csdn.net/younggift]

你最近在读什么书，及CSAPP上的一个疑问

"你最近在读什么书？"这句话我在两处看到过。一处是鲁迅先生关怀青少年成长，问某个孩子的，然后向他推荐了《表》这样的道德教育类少儿读物；另一处是贾宝玉问林黛玉，或者反过来，或者是薛宝钗问林黛玉，又或者是贾政问贾宝玉，也许是关心，也许是调情，也许是暗藏机锋，《红楼梦》里这种比生活还复杂的对话，我总也不敢说看懂了。反正有此一问。

最近在douban上看到某位地下书店店员的回忆，写得颇有大家风范，我深以为这是文艺工作者在体验生活之后交的报告。此地下书店中的地下，不是隐藏非常深而不得见的意思，而是真的就在地底下，可能是地铁，也可能是防空洞，我没注意。作者提到很多有意思的小细节，比如证明读者们都如何无知而装作有见识，讲到读者寻求推荐的时候问"最近得诺贝尔奖那个，他的书有没？"，似乎并不知道"莫言"。生活在观察之中，作为店员生活得颇有情趣。他提到两件事很有趣，一个是午休的时候挤出时间看溜冰，溜冰的人像水里游泳的鱼，另一个是提到很多明星去买书，他们都买实用型的

(例子可能是，如何治疗拖延症？)，只有周迅是个例外，她只买世界名著。

有人可能撇嘴了，"她们都是装的。"一则，人不能处处假装，比如在素不相识的书店店员面前，周迅如何得知这是位文学大家在卧底；二则，又如果周迅只钟看看微博传八卦，喜欢不超过三百字的贴子，但是她只买世界名著，这又不是她所钟爱的，那么她的生活得多么得痛苦啊。

有同学可能说，看看微博怎么了？看微博当然没什么，不过这语气总归有点像李某某的律师的语气，所有回答都是"这是俺们的合法权利"。看微博，就像有人喜欢吃方便面，喜欢吃方便粉丝，喜欢吃咸菜，总也不吃还非常想得慌。你可能会说，微博就方便面，世界名著就满汉全席。没错，我非常明确地认为，作品确实是分三六九等的，无论是思想境界，抽象的高度，还是什么。微博这样短小的文字，甚至包括博客这种篇幅，要是能让一个人进步，或者如某些人回忆到的看了读者知音故事会心灵鸡汤以后提着喷壶灌顶一般顿悟，那都怪了。

我们读那些短小的东西，只是为我们的观点、既有的知识结构找些佐证。就像小女孩左看看右看看，啊，原来大家都跟我一样胖，恩，放心了。这种感觉。颠覆我们观点的，让我们从另一个角度看自己，甚至否定自己的--这就是所谓成长--只能是足够厚的作品。或者偶尔，会有非常薄的作品起到这样的作用，比如离散数学，比如纯粹理性批判，比如爱因斯坦讲相对论的原始那张贴子，不过，无一例外，这种短贴子，非常之难看懂，你得花比看大部头还长的时间去读。

读短东西，我们不过是在自言自语，连反刍都算不上。

我固执地认为，程序员仍然是先进生产力的代表，一个重要原因是，他们在工作以后仍然保持读书。他们终日阅读，读的东西还都够长。

也许他们读的文字只是库函数手册，又或者需求书，但是他们在与别人进行相当精确和深入的交流。有些人也读了，但是只流于表面，用于证明关系，"啊，我也这么想，你看我们的关系多么铁"，或者"我完全同意你说的，但是"，或者双方各说各话，互无交集。程序员要精确地找出他反对的部分，然后与作者争辩，或者做实验，或者吵得面红耳赤。因为如果双方的观点完全相同，就连交流的必要都没有。这和我们变态的现实生活如此不同，在现实世界，往往观点相同，我们就要一万次确认，观点不同，我们甚至不再说一句话。在现实世界，我们竟然往往只与自己对话，这多么孤独和变态。还是做个程序员更正常。

他们所阅读的，并非自己或自己的同类，那些完全赞同自己观点的人，所产出的东西。不是有些人说，某某类的作品，口戚，我从来不看。以此给自己贴个值钱的标签，供人给些好的品评。毛泽东同志在瑞金的时候，据说曾有人说，你用孙子兵法指导革命战争，如何如何。毛同志说，你知道孙子兵法里面讲些什么，你知道孙子兵法一共有几章？不是有人只读我们自己的传统，不是有人只读非我们自己的传统的东西么。

同时，他们所阅读的，并非完全为了追求阅读当时的的和短暂的快乐，像有些文艺青年那样。他们的阅读是漫长而痛苦的，他们阅读的原因之一是为了追求阅读之后达成的共识，或者挖掘出的差异。这些共识和差异，可能是人与人的，也可能是我们的假想与真实世界之间的。所以，他们不只挑那些读起来爽的，听起来的好的。

这让我想起以前提到过的，小资们艳羡，李安有段时期由老婆供养，成天就是看片儿。看片儿之于李安，与小资们想像的是不同的，我相信，他一定不会只挑自己喜欢的看，还喝着汽水嗑着瓜子，他一定是把那些烦得不行的片子也要看了，看到吐，他一定是把自己喜欢得不行的片子也看了，品评分析很多遍，直到把骨头和肉和神经完全分开了，再也不是最初感情上肤浅地喜欢的那种。

程序员就是这样阅读的。而且，他们一直保持。

还有一些人，从成年 (成熟？腐烂？)开始，就再也不阅读，再也不阅读自己不"喜欢"的，再也不阅读长的，再也不阅读自己不认同或者不认同自己的，再也不阅读对业务

(比如宫斗或者宫斗)有用的任何书籍。他们少年时，读得最多的是考试辅导材料。他们成年时，读得最多的是他们的孩子的考试辅导材料。有些人，即使在工业社会，即使在后工业时代，仍然保持着光荣的传统的小农意识，除了圣经或者语录基本没有读过别的，除了家乡

(不管出生在多么大的城市)再没见过更广阔的土地。如此纯洁，不沾纤尘。

你最近阅读的，不是为了直接的短期见效的功利的动机，超过500页的作品，是什

么？

-----

附记：

今天读CSAPP，第9章。有一处卡住了一个小时，复核书上计算的结果怎么也不对。后来拿着书睡着了。拿着书睡着这件事，一点也不浪漫，它让我意识到衰老，也让我意识到没有读到什么好玩的东西，时光虚度。

CSAPP英文版第2版，826页，或者中文版第2版546页，有这么一段。关于多级页表的。

"But if we had a 32-bit address space, 4KB pages, and a 4-byte

PTE[page table entry, 杨注], then we would need a 4MB page table

resident in memory at all time..."

就这么一段，成了拦路虎。我跳过它，读了后面大半小节，没什么障碍。我是这

么翻译和理解的：

但是如果我们有一个32位的地址空间，每页长度4K字节，PTE每个为4字节，那么，我们将需要4M字节的页表一直驻留在内存中...

以上翻译，有几处需要解释。1.K是1024，不是1000，M是1024*1024，不是1000*1000。2. 4KB

pages，第一篇时我读错了，以为是4*1024页，又重读和读后面，发现作者习惯于这样措辞，其实是每页4KB这么长，即 "splitted

into pages of 4KB page size"。

然后，我按上述理解算了一个小时，没算明白。对不上。

其实这个公式很简单，我甚至google了一下以确认

页表尺寸 = (地址空间 / 页尺寸) * PTE入口大小........公式1

你按我上面的翻译手算一下左边和右边就知道了，不等。为什么不等呢？因为4KB中的B，还有4MB中的B，根本就不是"字节" byte，而是"比特" bit。

网络 (和中文？)中，习惯用 B 表示字节，b表示比特。但是CSAPP这段并没认可这个约定。

32-bit address space: 2^32 bit

4KB pages: 4K bytes

a 4-byte: 4 bytes

又

K = 2^10

M = 2^22

代入公式1的右侧，得

(2^32 bits / 4K bytes) * 4 bytes

= 2^32 * 2^2 / (2^2 * 2^10) bits

= 2^22 bits

= 2^2 M bits

= 4Mb

CSAPP原文和翻译均写作： 4MB

我是不是哪儿算错了啊，各位大师看出来的烦请告诉我。

--------------------

博客会手工同步到以下地址：

[http://giftdotyoung.blogspot.com]

[http://blog.csdn.net/younggift]

除了管道和重定向，还有命令行参数

管道和重定向，在Unix Shell

Script入门教程里都要提到。在稍微深入一点的dos/windows批处理教程里也要提到。管道，一般在用前一个进程产生的输出，作为后一个进程的输入；重定向，一般用在把输出由控制台转到文件，或者用文件替代控制台输入。管道和重定向满足了进程的输入和输出的转向。

输入和输出，似乎本来就是进程跑起来以后唯一与外界的联系。根据与外界的联系判定那是个什么东西，而不是根据它的内心，这据说是萨特的观点，小资们不可不知。

不过，输入和输出，并非进程与外界唯一的联系。除了输入以外，命令行参数，也是设定进程行为的重要依据。在这一点上，如果把进程当成一个对象，命令行参数有点像构造函数的参数，虽然跑起来以后就跟它无关了。而且，unix程序一般地，只有命令行参数才是命令，影响进程的行为，而以后从标准输入读进来的所有东西，都只是数据而已，是被进程处理的东西，对进程本身没有影响。

shell (像python一样)，是一种不错的粘合剂，它能组装一系的进程，让它们协同工作。管道和重定向，能让它们完成生产者-消费者这样的组合。

不过，如果我们需要一个进程的输出，不是作为另一个进程的输入，而是作为它的命令行参数呢？

下面的写法，

a | b

完成的，是把a的输出作为b的输入。

而如果我们希望下面这样，如何表达？

b -para <此处是a的输出>

有不止一种方法。

1. backtick

backtick，就是"`"。这不是单引号，而是键盘左上角，波浪线 (~)下面的那个小点，像个反向的单引号。

它的作用是，把括起来的命令执行了，并用执行结果中的每一行去替换命令所在的位置。

ls `echo -l`

相当于

ls -l

我们把其中的一段拿出来单独执行一下。

1 $ echo -l

2 -l

可见，"echo -l"的结果，就是"-l"。其中的""中为了避免echo把"-l"当成自己

的参数。

而"-l"替换了"ls `echo -l`"中反引号括起来的部分，所以"ls `echo -l`"就

变成了"ls -l"。

再举个例子。

1 $ grep -w main `find . *c`

2 ./samples/hidraw/hid-example.c:int main(int argc, char **argv)

3 ./samples/trace_events/Makefile:# have that tracer file in its main

search path. This is because

4 ./Makefile:# $(vmlinux-main). Most are built-in.o files from

top-level directories

5 ./Makefile:# +--< $(vmlinux-main)

6 ./Makefile:vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)

7 ./Makefile:vmlinux-all := $(vmlinux-init) $(vmlinux-main)

8 ...

这条命令的作用是，先执行 "find . *c"，找到当前目录下所有子目录中的 c文件，然后对每个符合条件的文件执行 "grep -w main"。

命令"grep -w main `find . *c`"中，`find . *c`部分将被替换为很多个匹配的文件名，然后每个文件名都作为

"grep -w main"的命令行参数，类似于：

grep -w main a.c

grep -w main b.c

grep -w main c.c

这样。

2. $(cmd)

backtick倒是挺方便，不过很多同学反映，"`"这个符号太丑陋了。最丑陋的特性之一就是，它跟单引号"'"长得太过地相似了。像我这样认人脸有困难的，本来就希望大家服饰发型更多样化一些，所以你能够理解我现在看到女演员们长得都越来越像，该是多么大的困惑。我指的不光是韩国的，小锥子脸大眼睛面孔白而无表情。backtick也存在这样的问题，跟别人像，本来就是毛病。

所以有别的写法，比如这样:

grep -w main $(find . *c)

这样的效果跟backtick是一样的。一样一样的。区别呢？多少也有一些。比如 $(cmd) 这样写法是可以嵌套的。

3. xargs

不过上述这些需要"代换"的，似乎有些程序员理解起来有困难？后来出现了一个命令，xargs，专门用来做这件事。

find . *c | xargs grep -w main {}

请注意到find和grep的顺序换了。find的输出结果，由xargs转给grep作为命令行参数。事实上，是xargs调用了grep，管道的末端不是grep，而是xargs。这不同于管道的末端是grep，如果是这样，就成了find的输出作为grep的输入，是管道应用的更一般的情况。args把管道的输出转向了grep的命令行参数，而不是作为grep的输入。

"{}"在这里，将被find的输出替代。如果命令行参数的位置不重要，或者在最末端，那么还可以把"{}"省略掉，效果是一样的。像这样：

find . *c | xargs grep -w main

4. -exec

似乎有了xargs以后，还是有些程序员觉得不够简单？又有些命令自带了"-exec"参数，意谓：如果匹配了，就把那些输出作为"-exec后面的进程的命令行参数"。话说，有些事情由于它的领域模型就那么复杂，是不太可能因为表达方式而变得简单的。

以下命令，效果是一样的：

find . *c -exec grep -w main {} -nH ;

行尾的";"，是为了标识"-exec"部分结束，其中的""是因为";"是个特殊字符。grep需要"-nH"参数，是因为不然输出的匹配行里没有文件名和行号。grep在此前的几个命令里用的是别名，这里是真正的grep本身。

5. 总结

以下几个命令等价：

$ cat `which 20.sh`

$ cat ${which 20.sh}

$ which 20.sh | xargs cat

cat不支持"-exec"参数，那是find这样的复杂命令的特色，因此以上总结中未包括。

----------

本文的命令在 emacs eshell 不好使，因为 eshell 对管道支持不充分，shell-mode则没有问题。

--------------------

博客会手工同步到以下地址：

----

杨贵福

东北师范大学计算机科学与信息技术学院

--

Sincerely,

YANG Guifu

School of Computer Science and Information Technology

Northeast Normal University

Changchun, P.R.China

重剑无锋，大巧不工。

无不大工。