Programmer

这也是在ChinaUnix上看了几篇关于C语言’位域(Bit Fields)‘的帖子之后，才想写下这篇文章的。其实在平时的工作中很少使用到’位域’，我是搞服务器端程序设计的，大容量的内存可以让我毫不犹豫的任意’挥霍’^_^。想必搞嵌入式编程的朋友们对位域的使用应该不陌生吧。这里我也仅仅是凭着对C语言钻研的兴趣来学习一下’位域’的相关知识的，可能有些说法没有实践，缺乏说服力。 ...

下午到ChinaUnix C/C++版看了看，发现一个比较有意思的问题，一位兄弟在其帖子中问一段很简单的程序明显有数组越界访问之错误，可程序为什么运行起来却’安然无恙’，我看看了看，也给出了我自己的回复，晚上下班后又想想了这个问题，决定写一篇blog说说。 这位仁兄的程序(据他个人说来源自’GNU/Linux编程指南’)是这样的： ...

关于内存对齐的话题，始终是敏感的。稍有不慎，必将闯下大祸！最近项目稍显轻闲，自己给自己安排一天反思和总结一下，突然想到以前写过的一篇’也谈内存对齐’，那篇文章谈的是内存对齐的基本知识以及一些实验的数据，想必很多人看完后，会收获一些东西，但是对内存对齐的应用还是处于懵懂状态，其实大部分时间我们是不会显式的用到’内存对齐的’，但是有些时候我们需要这样做。这里做了一个小例子，希望能给大家以启发。 ...

上午我们的一个实施组从现网发回来一封邮件，接到这种邮件一般都是报告问题的，果然不出所料，现场出现一个core，经过分析这是个由于线程函数参数存储位置不当造成的，从中我们可以总结出一些经验，以避免以后再犯。 ...

我们知道父进程在子进程被fork出来之前打开的文件描述符是能被子进程继承下来的，但是一旦子进程已经创建后，父进程打开的文件描述符要怎样才能传递给子进程呢？Unix提供相应的技术来满足这一需求，这就是同一台主机上进程间的文件描述符传递，很美妙而且强大的技术。 ...

记得刚到公司做第一个项目时，mentor要和我一起看看我刚实现完的一些代码，当时有些不解，难道是不相信我写的代码么？最后事实证明：我的代码中有很多缺陷，有的还是很严重的缺陷。后来知道这个过程叫’代码评审’，是保证软件质量的一种手段，而且是很重要的一种手段。代码评审的形式有多种，最正式的一种就是召集公司或者部门的一些’大牛’们，围坐在会议室中，一行一行的审查你的代码；简单的形式就像我和mentor做的那种，一个编写代码的人和一个对系统特别了解的人在一起评审，效果不见得不如正式的评审，起码我是这么认为的。 ...

下午一同事发现代码中的一处问题，问题的现象是这样的：这位同事调用了一部门基础库函数，当使用32位编译后，程序正常运行；而当使用64位编译后，系统运行dump core。让这位同事奇怪的是他所修改的程序中还有其他模块也使用了同样的基础库函数，为什么偏偏他这块儿出错呢？恰恰该程序的其他模块是我写的。 ...

在我的评论栏中有人说：“你是程序员?"，我可以确定、一定以及肯定地告诉他/她：‘我就是一个程序员，如假包换’。也许是最近技术类的blog写得少了，其他类的多写了些，让人家误会了，这也无可厚非。不过我倒是想到这样一个问题：程序员一定要满篇地谈技术么，程序员也有自己丰富多彩的生活呀。好了，切入正题。今天我们谈谈算法时间复杂性的分析。我没系统学过，都是在书上看到的以及MIT算法导论课上听到的。这里仅从我的理解的角度写一些罢了，不是很严谨哟。^_^ ...

又是老生常谈-‘单元测试’，说实话自己在单元测试上是’语言上的巨人，行动上的矮子’，属于那种说的比做的多的人^_^。不过也不能说什么也没做。记得去年年末的时候自己还设计并实现过一个简单的’C语言单元测试包‘呢^_^，至今这个包仍然还在使用呢。不过大多数的单元测试都不像想象中那样简单，我们在介绍单元测试的时候，大多拿Add、Sub等作例子，这样当然有好处，简单易懂。其实学习单元测试初期关键是学习单元测试的思想，所以这些Add、Sub也能满足需求。不过在真正的项目中，单元测试大多做起来较为困难，我是在Unix上做C开发的，Java的咱暂先不提，也没什么资格提，虽然曾经花过一段时间专心研究过，还写过些Java学习心得，但是毕竟没做过实际的项目，说起来心里也发虚。 ...

Pseudocode，即伪码，它常常用来描述一个算法，目的是能使被描述的算法能够容易的以任何一种计算机程序语言实现。’Pseudocode Conventions’可以理解为’伪码约定’，既然是’约定’那就并非强制性的标准。但是在专业的有关算法的文献和资料中，其相关内容多符合这些’Pseudocode Conventions’。如果你是一个想学习和钻研算法的人，那么建议你熟悉这些’Conventions’，俗话说：’磨刀不误砍柴工’吗！ ...