2011年我的确读了不少书，掐指算来纸版和电子版加在一起近50本，其中以技术类居多，但其他方面的也有一些。这里列出来做个简单回顾。 一、技术类 · 《你必须知道的495个C语言问题》 早在这本书出版前，其译者已经在网上完成了C FAQs的翻译(在这里)。这本书是基于最新C FAQs做了重新整理(包含C99)。虽说是最新，但因C语言近几年来变化很小，内容与之前译者在网上公开的那个免费版本相差不多。这本书适应面很广，初学者可以从中了解到很多谭氏教程中没有的东西；有经验的C程序员可以把它当成一本手册，需要时翻看。对于那些很在乎C语言细节的程序员来说，翻看一遍也未尝不可。 ...
2011年眼看就要接近尾声了，这里也对自己在2011年的"所作所为"做个小结^_^。 这一年来工作之外的我过得还是比较充实的，从下面的数字也可以看出： - 写了81篇博文 - 开源了2个工具(CBehave和buildc) - 合译了一本书（"Seven Languages in Seven Weeks"，不过尚未出版） - 读了近50本书（通过豆瓣读书统计） - 新学了一门语言 – Common Lisp - 新用了一门语言 – Python ...
这几年我一直从事C语言项目的开发。这些项目的规模都不算小，少则十几万代码，多则几十万行代码，至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make工具，构建脚本都是自行编写的，构建时直接在顶层目录下敲入make即可。 这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量；你还要将项目依赖的各种内部公共库、第三方开源库悉数找到，并安装在指定目录下，修改Makefile中这些第三方库的路径配置。只有做完这些后，你才能顺利地执行Make。以后每当你更换一个环境，你就要将上面的步骤重复执行一遍。有的项目第三方依赖较多，要完整地搭建一个项目构建环境所耗费的时间也是很惊人的，特别是对一些不熟悉项目构建的新人更是如此。另外随着产品被要求具备在多个平台上运行的能力，你的构建脚本还要支持在多个平台上的构建，你要为项目所依赖的第三方库准备多个平台的版本；当某个依赖库版本进行了升级，你还要手工在多个环境下进行更新。 ...
我们在平时编码过程中很少考虑代码的安全性(security)，与正确性、高性能和可移植性相比，安全性似乎总被忽略。昨天从安全性角度泛泛地Review了一下现有的代码，发现了不少具有安全隐患的地方。我们的程序员的确缺乏系统地有关安全编码方面的训练和实践，包括我在内，在安全编码方面也都是初级选手，脑子中对安全性编码缺乏系统的理解。 ...
我不是知识管理领域的专家，但我认为知识的积累和管理对一个期望长久稳定发展的组织来说很重要。今天我这个"门外人"就来说几句"门外话"。 我所在的部门已经成立10余年了，但说实话部门在知识积累和管理方面做的比较一般。例如，没有统一的知识积累和管理平台，知识分享多靠mail列表，或将知识存储在文件中放入Microsoft Visual SourceSafe，若干日子后，再无人能找到之前的知识(VSS绝对不是一个知识管理平台，顶多就是一个版本管理工具，还是个有些落伍的工具)；没有专人负责知识积累和管理；知识积累与管理似乎始终是优先级最低的那个任务。 ...
restrict关键字是C99标准中新引入的一个类型修饰符(type qualifier)。如果你看过GNU C库的源码或是其manual，你就会发现restrict修饰符被广泛地应用在GNU C库中。restrict关键字到底是用来做什么的呢？估计很多对C语言细节研究不够的程序员都无法给出答案，我个人也只是停留在"知道"这一关键字的层次上，于是乎今天我又对着C99规范钻研了一番，略有收获，这里也说道说道。 为何C标准委员会要在C99标准中引入restrict呢？这当然是有历史原因的。我们先来看看下面这个例子： /* foo.c */ void foo(int *p, int *q, int *r) { *p += *r; *q += *r ; } ...
上个周末花了些时间将《Pro Git》（Git高手进阶之必读书籍，严重推荐^_^）快速地浏览了一遍，在感叹于Git强大的同时，也见识到了Git的复杂。可以肯定的是Git学习曲线远没有学习Subversion那样平坦。比如，Subversion工作目录下的文件只有三种状态：Untracked、Modified和Committed(即Unmodified)；而以Git本地工作目录下则有四种状态：Untracked、Staged、Modified和Committed(即Unmodified)。虽然只多出了一种状态，但感觉其复杂度又上了一个台阶。 Git在这里只是一个引子，我真正要说的还是设计模式，只不过这个模式对应的例子实现与Git的一个命令相关罢了。这个命令就是Git status。Git status可以根据当前工作目录下文件的不同状态输出不同的提示信息，例如，对于工作目录中处于"未跟踪"状态的文件foo.txt，Git会输出下面信息： $ git status # On branch master ...
提到Transaction模式(即事务模式)，很多人会感到陌生。这并不奇怪，在大名鼎鼎的GoF的《Design Pattern》一书中，它仅仅是Command模式的别名罢了。不过在实际的开发中，我们却经常会遇到可以应用事务模式的场景。本文可以理解成Command模式在事务领域的应用，但这样说有些麻烦，我们莫不如直接称之为Transaction模式。 与前几篇设计模式C实现系列文章一样，这篇文章也源于对实际问题的思考和总结。这次的问题是这样的：我们的业务系统实现了一个ftp上传文件的功能，其v1版代码的结构简化后大致如下： int ftp_upload_file(const char *filename, const remote_server_desc *desc) { int ret; ...
当前任何一个组织 — 无论是私企，还是国企，无论是政府还是民间组织，无论是在国内还是在国外 — 都在强调提高效率。但"提高效率"不简单是一句口号，还需要脚踏实地的真正去做。 ...
又是一个行为类的模式，似乎这类模式在使用C语言开发的项目中适应性更强，而另外两类模式创建型和结构型则略显不受待见^_^。 Chain of Responsibility模式（中文名：职责链模式）是一个不算复杂的模式。虽不复杂，但用好了同样可以解决大问题。个人觉得其最大的好处就在于可以动态地重组针对一类对象的处理流程。正是得益于这一优势，它才可以在纷繁芜杂的业务领域站稳脚跟。 ...