IT牛人博客聚合

这几天，安排新来的王同学做数据持久化工作。一开始他是将 sharedb 里的数据序列化为文本储存的。这步工作做完后，开始动手把数据放到 Redis 数据库中。我们的系统主干由 Lua 构建，所以需要一个 Lua 的 Redis 库。google 来的那份，王同学不满意。三下五除二自己重写了一个。据说把代码量减少到了原来的三分之一（开源计划我正在督促）。唯一的问题是，如果直接采用系统的 socket 库，不能很好的嵌入我们的整个通讯框架。我们的 skynet 全部是通过异步 IO 自己调度的，如果这个数据服务单方面阻塞了进程，会使得别的进程获得不了时间片。

蜗牛同学打算改进 skynet 增加异步 IO 的支持。

我今天在考虑现有

查看全文: http://www.udpwork.com/item/7057.html

过年了，人都走光了，结果一个人活也干不了。所以我便想找点东西玩玩。

今天想试一下 libev 写点代码。原本在我那台 ubuntu 机器上一点问题都没有，可在 windows 机上用 mingw 编译出来的库一个 backend 都没有，基本不可用。然后网上就有同学推荐我试一下 libuv 。

libuv 是 node.js 作者做的一个封装库，在 unix 环境整合的 libev ，而在 windows 下用 IOCP 另实现了一套。看起来挺满足我的玩儿的需求的。所以就试了一下。

这东西没有文档，暂时没看出来作者有写文档的打算，恐怕他是自己用为主。我 google 了一下，就是 github 上有源代码，.h 文件里有还算比

查看全文: http://www.udpwork.com/item/6731.html

其实铁路订票系统面临的技术难点无非就是春运期间可能发生的海量并发业务请求。这个加上一个排队系统就可以轻易解决的。

本来我在 weibo 上闲扯两句，这么简单的方案，本以为大家一看就明白的。没想到还是许多人有疑问。好吧，写篇 blog 来解释一下。

简单说，我们设置几个网关服务器，用动态 DNS 的方式，把并发的订票请求分摊开。类比现实的话，就是把人分流到不同的购票大厅去。每个购票大厅都可以买到所有车次的票。OK ，这一步的负载均衡怎么做我就不详细说了。

每个网关其实最重要的作用就是让订票的用户排队。其实整个系统也只用做排队，关于实际订票怎么操作，就算每个网关后坐一排售票员，在屏幕上看到有人来买票，输入到内部订票系统中出票，然后

查看全文: http://www.udpwork.com/item/6686.html

很久没有写工作笔记了，如果不在这里写，我连写周报的习惯都没有。所以太长时间不写就会忘记到底做了些啥了。

这半个多月其实做了不少工作，回想起来又因为太琐碎记不太清。干脆最近这几天完成的这部分工作来写写吧。

我在 开发笔记 第四篇谈到了 agent 的处理流程。但实际操作下来还是觉得概念显得复杂。推而广之，对于不是 agent 的服务，我需要一个通用的消息处理框架。

对于每个服务器，可以看成是对一组约定的服务协议进行处理。对于协议分组，之前我有许多想法，可做下来又发现了若干问题。本来我希望定义出一个完整的 session 概念，同一个 session 下，可以分不同的步骤，每个步骤都有一个激活的协议组。协议组之间可以共享状态，同时

查看全文: http://www.udpwork.com/item/6669.html

最近工作有点感触， 关于如何分工的。

我觉得所谓设计和实现是无论如何都很难分拆出去的。就是说你不实现你设想的结构，永远都很难知道哪里有问题；即使没有问题，换一个人来实现你想的东西，也无法把设计意图全部传达过去。如果可以做到，那么耗费的时间和精力足够你自己来实现了。

这也是为什么我之前说，软件项目需要很多人一起完成可能是一个骗局 。但毕竟，一个人精力有限，项目时间也有限。分工是无奈之举。可这件事情怎样做才对呢？

我最近有所体会的还是那些被嚼过很多年的老道理。就是模块划分清晰，强内聚，低耦合之类。想强调的是，模块的层次一定要适中，同一层次上规模不能太大，有严格输入、输出接口。

这些并不是为了方便测试，检验工作正确性，而是为了拆分

查看全文: http://www.udpwork.com/item/6666.html

今天吃晚饭的时候想到，我需要一个定制的内存分配器。主要是为了解决 共享内存 中的字符串池的管理。

这个内存分配器需要是非入侵式的，即不在要分配的内存块中写 cookie 。

而我的需求中，需要被管理的内存块都是很规则的，成 2 的整数次幂的长度。buddy memory allocation 刚好适用。

算法很简单，就是每次把一个正内存块对半切分，一直切到需要的大小分配出去。回收的时候，如果跟它配对的块也是未被使用的，就合并成一个大的块。标准算法下，分配和释放的时间复杂度都是 O(log N) ，N 不会特别大。算法的优点是碎片率很小。而且很容易做成非入侵式的，不用在被管理的内存上保存 cookie 。只需要额外开辟一个二叉

查看全文: http://www.udpwork.com/item/6560.html

开始这个话题前，离上篇开发笔记已经有一周多了。我是打算一直把开发笔记写下去的，而开发过程中一定不会一帆风顺，各种技术的抉择，放弃，都可能有反复。公开记录这个历程，即是对思路的持久化，又是一种自我督促。不轻易陷入到技术细节中而丢失了产品开发进度。而且有一天，当我们的项目完成了后，我可以对所有人说，看，我们的东西就是这样一步步做出来的。每个点滴都凝聚了叫得上名字的开发人员这么多个月的心血。

技术方案的争议在我们几个人内部是很激烈的。让自己的想法说服每个人是很困难的。有下面这个话题，是源于我们未来的服务器的数据流到底是怎样的。

我希望数据和逻辑可以分离，有物理上独立的点可以存取数据。并且有单独的 agent 实体为每个外部连接服务。这

查看全文: http://www.udpwork.com/item/6532.html

我一直不太满意 google protocol buffers 的默认设计。为每个 message type 生成一大坨 C++ 代码让我很难受。而且官方没有提供 C 版本，第三方的 C 版本 也不让我满意。

这种设计很难让人做动态语言的 binding ，而大多数动态语言往往又没有强类型检查，采用生成代码的方式并没有特别的好处，反而有很大的性能损失（和通常做一个 bingding 库的方式比较）。比如官方的 Python 库，完全可以在运行时，根据协议，把那些函数生成出来，而不必用离线的工具生成代码。

去年的时候我曾经写过一个 lua 版本的库 。为了独立于官方版本，我甚至还用 lpeg 写了一个 .proto 文件的解析器。

查看全文: http://www.udpwork.com/item/6439.html

去年谈过 C 语言对模块化支持的欠缺。我引入了一个 USING 方法来表达一个 C 语言编写的模块对其它模块的依赖关系。用它来正确的处理模块初始化。

现代语言为了可以接近玩乐高积木的那样直接组合现有的模块，都对模块化做了语言级别上的支持。我想这一点在软件工程界也是逐步认识到的。C 语言实在是太老了。而它的晚辈 Go 就提供了 import 和 package 两个新的关键字。这也是我最为认可的方式。之前提到的方案只能说是对其拙劣的模拟。确认语言级的支持，恐怕也只能做到这一步了。

在项目实践中，那个 USING 的方案我用了许多年，还算满意。之前有过更为复杂“精巧”的方法，都被淘汰掉了。为什么？因为每每引入新的概念，都增加了新成员

查看全文: http://www.udpwork.com/item/4787.html

Effective C++ 3rd 的评注版要出版了。我在这本书上花了不少心血。编辑约我最后写一篇序。我新码了点文字，用了点以前 blog 上写的旧文。

今天侠少同学说“现在全文看下来还是有些纠结，反对、支持、再反对，再支持，百转千回的小情绪，读者恐怕会犯晕”。嗯，的确很羞愧的。不应该在这本大牛的书前面发牢骚。打算晚上改稿子。旧稿就贴这里存档吧。

序

2010 年秋电子社编辑侠少寄给我一本Effective C++（第三版）英文原版书，并托我为这本书写一些评注，希望做成评注版在国内出版。老实说，之前我并无阅读这本书的计划。
通过更深入地理解 C++ 而获得一种喜悦感，是十多年前的事情了。那时我刚刚从 C 语言迁移到 C++ 来

查看全文: http://www.udpwork.com/item/4696.html

这几天认真玩起了 Go。所谓认真玩，就是拿 Go 写点程序，前后大约两千行吧。

据说 Go 的最佳开发平台是 Mac OS ，我没有。其次应该是 Linux 。Windows 版还没全部搞定，但是也可以用了。如果你用 google 搜索，很容易去到一个叫 go-windows 的开源项目上。千万别上当，这是个废弃的项目。如果你用这个，很多库都没有，而且语法也是老的。我在 Windows 下甚至不能正确链接自己写的多个 package 。活跃的 Windows 版是 gomingw ，对于 Windows 用户，装一个 mingw32 以后就可以开始玩了。

就三天来实战经历，我喜欢上这门新语言有如下原因：

mix-in 的接口风

查看全文: http://www.udpwork.com/item/3467.html

今天终于把作业作完了（可能还有地方要返工），Effective C++ 第 3 版读完了，写了几万字的评论。如我给编辑交稿的 email 里所写：

我觉得评注这个工作比翻译难做。作者细节上讲的非常清楚，大部分地方都不觉得有必要再加注解。我想跟这本书反复写了 10 年有关。所以很多页我都没留评注，真的不知道可以写啥。

编辑原想每页中英分列排版，我是不建议这样的。除了少部分评注，针对个别代码段，或关键词。大部分我的文字都是独立成段的。跟具体原文句子关系不大，只跟篇章段落主题有些许联系。

前几天跟孟岩兄 email 交流，我发了一些稿子给他。他觉得关于本书第一篇 Item 1 : View C++ as a federation o

查看全文: http://www.udpwork.com/item/3180.html

最近一个多月的业余时间都耗在了《Effective C++ 3rd Edition》这本书上。读的很辛苦，不仅仅是因为这是本英文书。之前答应了博文的编辑帮这本书写评注，将来用于出版。对于要印成白纸黑字的文章，不得不谨慎一些。

我已经有 4 年没有大段时间写 C++ 代码了。中间偶尔有几天写过几千行，其余的 C++ 经验就来至于 google reader 上的阅读。为了读这本书，我又重温了《C++语言的设计和演化》的几个章节。不过整个阅读过程还是不太赏心悦目。

可能还是因为我对 C++ 偏见过多，有如前几年对其的推崇备至。总觉得书里讲的太细，太多观点本是好的，只是局限在了 C++ 语言中。明明是 C++ 的缺陷，却让人绞尽心力的

查看全文: http://www.udpwork.com/item/3109.html

去年介绍过我在项目中实现的一个动态数组模块的接口。

实际上，我为它提供的接口要更多一些，比如删除一个元素。

void array_erase(struct array *, seqi iter);

原来的语义就是删除 iter 引用的元素。但这里引出一个问题：删除后，iter 是否应该保持有效？

从语义上说，iter 应该在调用完毕后变成一个无效引用。但实际应用中，往往需要在迭代 array 的过程中，删除符合条件的元素。让迭代器失效的做法，用起来很不方便。

因为 array 其实是以一个双向队列的形式实现。以前我取了一个巧，删除这个操作实际上是把当前位置的元素和 array 头部的元素交换，然后将 array 头 pop

查看全文: http://www.udpwork.com/item/2537.html

有时候，我们需要把多个模块粘合在一起。而这些模块的接口参数上有少许的不同。在 C 语言中，参数（或是返回值）不同的函数指针属于不同的类型，如果混用，编译器会警告你类型错误。

在 C 语言中，函数定义是可以不写参数的。比如：

void foo();

这个函数定义表示了一个返回 void 的函数，参数未定。也就是说，它是个弱类型，诸如：

void foo(int);

void foo(void *);

这些类型都可以无害的转换成它。正如在 C 语言中，具体的指针类型如 int * ，char * 都可以转换为 void * 一样。

注1：如果要严格定义一个无参数的函数，应该写成 void foo(void);

注2：如果

查看全文: http://www.udpwork.com/item/2024.html

本篇是应《程序员》杂志约稿所写。原本要求是写篇谈 C 语言的短文。4000 字之内 。我刚列了个提纲就去了 三千多字。 -_-

现放在这里，接受大家的批评指正。勿转载。

C 语言的前世今生

C 语言，从 1970 年代设计并实现之初，它就注定了带有强烈工程师文化的语言，而缺乏一些学术气息。它的许多细节设计，都带有强烈的实用化痕迹。C 语言因 UNIX 操作系统而生，是 UNIX 系统的母语。这导致在这个广泛应用的操作系统上开发，必须通过 C 语言的形式和系统进行交互。这不仅影响了 UNIX 一个平台上的软件，既而也影响了后来世界上最大的桌面系统 Windows ，以及越来越多的嵌入式平台。

由于大部分应用软件最终都需要和操作

查看全文: http://www.udpwork.com/item/1921.html