未分类 - Page 22

铁子同学的太原科幻之旅，我检查嗓子的科幻之旅

今天中午见了铁子同学，一起吃了狗肉。为避免不吃狗肉的同学误解铁子同学，确切地说，我吃了狗肉，铁子同学有没有吃，我倒是没有注意。

吃完离开的时候，乌云密布，整个天跟日食一样黑。我们跑出饭店，发现外面狂风大作，湿气扑面。我们大喊，"跑啊！"冲进了正在开始密集的雨点里。我们的前前后后，很多人影穿棱而过，或者被我们甩在身后。刚钻进车里，风卷着雨水和尘土扑天盖地而来。

一边扑落脑袋上的雨点，我一边后怕。因为腰间盘，每当有雨都得分外小心了。在石家庄出差，顶着小雨打车，不到半分钟，我就很担心，结果果然等到电梯的时候，左腿已经瘸了。腰间盘突出会压迫脊椎的神经，这是突出以前很多人从来没想到的，腿疼居然会是腰的毛病。想想不少恐怖科幻类的动画片里，巨人吃人的时候，不是要把人的大脑和脊椎神经一起抽出来么。脊椎神经是人类的神经系统中重要的一环，密集程度仅次于脑。

而这一次也淋到了雨，还狂奔二百米，居然没有疼。可能，是因为铁子同学的年轻和热情传染了我。吃饭的时候，主要是他讲，我听，讲他前几天在太原参加科幻大会的情形。"我见到大刘啦，还有何夕也一起合影，我左拥右抱...小姬，小姬挺高的，夏笳也挺高；还有那谁也是，真高啊，快跟我一样高了...我坐了22个小时的车才到太原，还是硬座..."

他带回了一本特别厚特别硬皮的科幻牛人们的传记，要送给我。我说，你还是自己留着吧，给我真就白瞎了。迷上科幻以后很多年以后，我才知道，我根本不能算是科幻迷。像大刘老师那种大学期间就把各种八卦掌故 (及历史) 都了解得极其清楚，像铁子同学这种单程20多个小时往返硬座自费参会，才是真正的科幻迷。铁子同学说，那本大硬书，他要留给东北师大科幻协会。他说，他毕业的时候，要把一箱子书都捐给协会。我说，是啊，应该让更多的人能够看到。但是我却舍不得把一本书借给别人。在这里，我该呵呵还是嘿嘿一笑？

铁子同学感叹，这协会现在不好整啊。我脱口而出，现在大家都只想要成绩不想干活。他说，啥？愣愣得看着我。我的确没有想到，在他已经大四，同时协会已经不在团委列表中的情况下，他仍然把协会的发展视为己任。估计，我这句随便的抱怨刺激到了铁子同学。抱歉。其实，这并无针对性，并非你或者科幻协会给我这样的感觉，而是--与其说是因你这句而感慨，不如说--整个世界尽皆如此，令我失望。

我给铁子讲了什么？我说，我前两天去嗓子出毛病了，去医院，看到那个检查设备很科幻。具体是这样的。

我嗓子前一段总感觉像出血，咸，还有红色的东西。某一日，被不知道什么纤维扎进了扁桃体。什么，你问我吃哪种鱼了？天可怜见，上回吃鱼是和包师弟，吃的酥鲫鱼，被扎了，在右边扁桃体，约半厘米多长。再上次吃鱼，似乎已经是好几年前的事了。这次扎我的纤维，应该是某种蔬菜，白菜之类的。

医生揪住我的舌头拉出来，她额头上的灯的在我面前左晃右晃，说，"那不是血，是淋巴渗出液。"后来我跟大哥转述的时候，他说，"什么玩意，淋巴还能渗出呐？"我心里默默地替他翻译，"不明觉厉。"

医生继续揪住我的舌头，命令我，"说'衣~~'"。我试图把舌头抽回来，失败了，只好说，"哎~~"，心想，"不是一般都说'啊'吗？"

然后医生让我做电镜。怪吓人的名字，再次不明觉厉。不过拿到麻药小瓶的时候我就全明白了，某种麻醉剂，名字现在我一时没想起来，不过看到就知道是啥了。喝了，等。我以前拔刺的时候喝过，这是避免咽部本能的呕吐反应的。

躺在几块平板组成的椅子 (床？)上，一看那几块就是对应人大卸八块以后形状拼起来的。后脑勺正夹在一个坑里，45度侧对医生。我看着他，他的脑袋后面是个电视，手里拿个跟章鱼脚一样灵活而有韧性的黑线，线的末点晶光瓦亮。我盯着这黑章鱼弹跳，不由得想起《黑客帝国》里的Neo，那帮人按着它，把个很多条腿的家伙塞向他。

但是我表现得很勇敢，面对章鱼大张开口，无声大叫，"来吧。"医生看看我，温柔地说，"闭嘴。"

我闭上嘴，想，"看来是一会儿才检查，歇会。"正在此时，说时迟到时快，我的鼻子眼一痒，眼看他脑袋后的电视里出现了一团烂肉和毛发...还没等我反应过来，医生说，"不要怕，没事。"

原来，电镜是从鼻子进去的。我原以为和拔刺一样，从嘴进去。问题是，我没有怕啊，却完全无从解释，就跟拔牙的时候一样，只好瞪眼。

医生说，"不要怕，你别看屏幕能感觉好点，"，又一遍，"吸气。"

我吸气，管子从鼻子进到咽喉。

医生说，"说'衣'"。又是"衣"，所以我又困惑了一次，为什么不是"啊"。

再吸气，管子回到鼻子，然后就出去了。

医生说，"慢性咽炎，别喝酒别抽烟。"我说，"我..."想起了以前说是脂肪肝的时候，问医生咋整，他也说，"别喝酒。"我也被整得哑口无言。因为我根、本、就、不抽烟不喝酒。

想起了ZHUMAO的一段言论。他抽烟，同事说，"大夫不是说你嗓子坏了不让你抽么？"ZHUMAO说，"我嗓子没坏的时候，大夫也说别抽。"

妙答。那我不抽不喝的，却如何应对别抽别喝这样的要求呢。我只好小声说，"我喝咖啡。"医生看了我一眼，说，"啊。"

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

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

[http://giftdotyoung.blogspot.com]

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

特别特别繁忙的九月

特别特别繁忙的九月（照片有些好的，还没时间整理。）我曾经计划过，在CSDN上每个月都发4篇以上的博客，这样能始终挂着"持之以恒"勋章。九月，我只发了两篇，前一篇是刚刚开始忙碌，后一篇是发现忙碌貌似永无绝期，月底将至，尽力而为写的。这期间，我甚至都没有时间去考虑"啥时候能忙到头"这件事。以前有人说过，过一阵就好了，或者，这只是开头，以后就好了。我当时表达了反对，明天总是跟今天差不多，如果不是更坏的话。估计被鄙视了吧，不过事情却正是这样，王子与公主从此过上幸福的日子这种事，只有童话里才有，而且还得是在童话结束的时候。
九月之前，我保持每天读书4个小时，分门别类，各自有进度。就像大河上木筏子里的人，满怀希望地看着前方的地平线，两岸如画，柳风清扬，阳光和暖，心里盘算着，恩，还是多少公里折合多少天，我们就到入海口啦。然后就是港口和海鸥，大碗喝酒大块吃肉。可是，谁又知道下一刻暴风骤雨突然降临，河床塌陷漩涡急转，瀑布之声如雷贯耳就在左近。刚进入9月，我的整个读书进度几乎完全停滞。
你永远也想不到明天是个什么样子。当然，能看到明天，就是幸运了。就像一场游戏，你在战场上奋勇拼杀，而偶然因素像丛林里的野狼，在你左右窥伺。满以为发现了规律，比如金甲虫喷一会远程炮弹就仓库空虚，可以派小狗凑上前去群殴猛咬，你终于能放开手脚大干一场。突然，游戏的对方（可能是电脑）突然宣布，它输了；或者，敌人的空军从天而降，像一场大风，然后战场上你的兵全没了。无论是被敌人灭掉，还是敌人撒手不打了，都令人同样郁闷。
而我，只有呆坐在电脑前面。整个九月，我大部分时间就在电脑前傻坐着，屏幕上开着的主要是WORD。而大部分时间，我什么也没有键入，只是在想。或者，我站在白板前，半天也不画上一笔，我在等，等各个元素和它们的关系如水退潮，逐渐从迷雾里显现出来。什么时候，能不能，我也说不好，很没有把握。
罗素这样讨论过牛顿在太阳系各行星运行规律中的价值。他说:如果太阳系的流星们更大一些，牛顿定律就没多大价值了。因为更大的流星会经常把行星击打得四处翻滚流窜，虽然牛顿定律仍然是对的，甚至还可以根据它计算出流星与行星相撞以后各自的轨迹，但是这对于预测太阳东升月亮西落的时机难有帮助，更不用说对日食月食火星轨道的解释了。如果偶然因素在这个世界上占据了主要地位，那么，我们也不用再奢望预测未来了，连形成现在的那些规律也难以发现和了解。可是，如果未来一切注定，今天我们就能看到二十年后，那人生还值得去过么？
你可以想到，人生也许应该是那样吧，大河缓慢流淌，偶有微澜，又不至于落水。可是如果这一切都按你安排地去演，那和过家家又有什么区别。
九月，异常繁忙，没有时间写博客，也没有时间想更多。几乎，除了工作，就是倒头便睡。不过，我还是看完了CSAPP，从2012年11月至2013年10月；西方哲学史的前苏格拉底时代快要看完了。
九月过后，然后就是十月了。

去大连

早晨6：30起床，晚上21：00回到长春。这中间，我去了一次大连见老师。可能，你想到了梁朝伟提到的早晨在哪哪，中午在哪哪，晚上又回来，中间在哪哪喂了鸽子。

没那么浪漫，至少我的这一趟不怎么浪漫。

6：30起床，然后简单早饭。公交人很挤，路上车不是很挤。之后坐轻轨约1小时，到火车站，打印车票。这时8：00左右，基本没候车，检票上车了。

8:22，高铁从长春发出，奔向大连。一路无话，我拥有了难得的约三个小时的阅读时间。读CSAPP最后一章，读了两个小节；西方哲学史，读了一个小节多一点；《天行健》小说，第二部读超过一半。二等座挺挤的，对于稍微胖一点的人来说，可能就不能忍了。

11：50，大连。出站以后回头看，"大连"二字，硕大的暗红色，隐在雾气 (还是灰尘？) 里。打车去大连理工大学，预计车程1小时以内，结果30多分钟到达。司机一直很关心一个问题，"哪个门"。我也估计到了大学之大，所以事先查了地图，言之凿凿，"到了地方我就知道了"。结果司机提前拐弯了，进入我完全陌生的街道，我说，"绕吧，绕绕我们就找到了"。

最后，我提前下车，步行按指南针、GPS和地图找到了预定的目标。在百度和谷歌上都标着"化学楼"。

小广场上，有一群同学正写生。也许是写生，支着大画夹子，但是兴高采烈地样子，又似乎不像画画那么安静。我问某位同学，"请问化学楼怎么走？"

"化学楼，你问哪个化学楼？"

啊？居然有好几个化学楼。附近有几座楼，都有很长的名字，似乎其中都嵌了化学二字。那同学一指，"你找老某啊，应该就是那个。"

我蹭蹭爬上四楼。时间还早，但是我在见老师之前得先在走廊里或小广场台阶上把干粮吃了，免得见老师的时候血糖太低头脑迷糊。吃饭之前得先熟悉一下地形，免得到了约定的时间我还找不到地方。此时，距离约定时间还有1小时。

四楼，老师此前短信过我房间号。但是，当我到了四楼，傻了，老师告诉我的房间号里没有"ABCD"啊。这座楼的房间号，类似于201A，201B...。是这座楼么，我开始怀疑。

开始问路。我不知道1个小时的时间够不够我找到目标地址，饭暂时不能吃了。

我问路过的一位同学，请问这是"化学楼"么。她说，"化学楼...化学么...你问别人吧。"然后跑了。当时特别想找个镜子，难道我看起来很吓人？后来我又问了几位同学以后，开始逐渐明白了。

之后，我问了十位以上的同学。他们中，大多数不知道化学楼在哪里。没错，这十多位都是"同学"，至少根据我在大学里生活了近20年的经验，他们都是本校同学。对于这一点，我也很震惊。

当终于有一位同学说，"你问化学...是苯环儿楼吧"，我以为自己豁然开朗，我以为。原来应该问"苯环儿楼"啊。接下来的几位同学，对"苯环儿楼"这个名字也摇头，其中一位还问，"什么？北环楼，B环楼？"你知道，我口齿还算清楚，能快速说出几个绕口令。这位同学，似乎没有听说过苯环儿这种东西。

最后，一位同学指着就在我眼前的那座楼说，"估计你说的就是那个。"我打量下这座楼的边角，是的，差不多，看起来是个圈楼，而且极可能是六边形。

可能你已经开始质疑我的寻路能力了。不过，在以上半小时以上的过程中，我穿过小半个大连理工大学主校区，路径最短，中间还从梯子上翻过了一座墙。

见老师，谈了不到半个小时。老师拍着我的肩膀说，"行了，你回去吧。"我真想拍着他的肩膀说，"老师，你太够意思了。"但是辈份所限，这动作太没礼貌，没有实施。

半个多小时的出租车，我回到火车站。去麦当劳，坐了一个小时，吃刚刚计划但是没有进行的午饭。

15：30左右，去候车。候车室里有很多椅子，有更多的旅客。有些旅客站着，还有些坐着。坐着的旅客，很多把行李放在自己身旁的椅子上。对公共空间的侵蚀，我一向痛恨，但是现在我连问"这里有人么"也懒得问了。我想，这是年龄大了的一个标志，我已经没有热情参与这个世界的道德建设了。我想的是，就这么地吧，我自己旁边有空座的时候不去占就是了。

检票以后我注意到周围特别臭，是海鲜，估计很多人带，才会臭成这个程度。我这才想起来，白来一次大连，居然连只螃蟹也没有带回去。

16：13，高铁出发，大连至长春。因为返程的时间先前不能确定，需要根据老师指导的时间来定。所以，我离开大连理工的时候通知二猫妈，请网上定票，然后我到火车站打印车票。一等座，终于不再受那挤着的苦。

又3个小时左右的阅读时间，还是CSAPP，西方哲学史，天行健第二部，轮着看了一圈。窗外西沉的落日照亮原野和湿地，蓝天惭惭布满淡淡的云，然后慢慢黑了下去。我看着书页，眼皮开始打架。旁边的丝袜女在大声讲电话，"哎，你说我是不是有病啊，这两天我一听他说话就恶心呢，想吐"。我迷迷糊糊地要睡着的时候，在心里回答她，你可能真是有病，如果你打电话声音小点...后面的不再记得，因为我睡过去了。

19：58，长春。又1个小时的轻轨，21：00，我到家了。

早晨6：30左右出发，晚21：00返回。这中间，6个小时的火车，2个小时的轻轨，1个小时的出租车，半个小时的狂奔找路。我担心过这种强度腰间盘能不能扛得住，实践表明，戴上硬质护腰，虽然捂出不少汗，但是挺过来了。出发前跟董同学电话，他说，你一人在外，要小心啊。事实上，我确实恐惧。恐惧，可能是所有因素中，最令我最强烈地感觉到现实与理想的差距的。

曾经，我小学的时候吧，在地图上从通化画出一条线。先到长春，再到北京，再到祖国和世界的各个地方。直到大学入学，我第一次离开通化。那个时候，那么期待看到外面的世界，我从来没有想到，有一天，我会畏惧旅行。那个时候，年轻的我想的只有，"抬脚就走，有什么可怕。"那个时候，我不能理解更年长的人恐惧的来源，以为他们只是胆怯。那个时候，我也没有想到，所有这些城市，几乎都一样的建筑，一样地掩埋在灰尘雾霾之中。这座城市与那座城市也没有什么区别，你行万里路，看到的也只是相同的立面和街灯。

我也没有预料到，就像所有对未来充满美丽的期待的少年一样，我没有预料到，即使交通如何发达，即使在同一个城市，甚至在同一个校园，相距也一样遥远。人生不相见，动如参与商。生存的压力如此巨大，令我们不能相见相聚。甚至没有时间相互怀念。

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

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

[http://giftdotyoung.blogspot.com]

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

以前能跑步的时候

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

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

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

力上，转瞬即逝。

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

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

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

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

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

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

折磨人的事。

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

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

我只有呵呵。

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

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

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

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

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

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

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

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

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

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

时代也不怎么明显。

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

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

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

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

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

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

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

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

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

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

，说这能治我的手。

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

那么

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

当年很牛呢。

读赠卫八处士，听肖邦夜曲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 )。

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