近期公司实行新的绩效考核机制，我的考核目标中就有一项叫做："成功使用新技术、框架、思路等至少3个"，呵呵，先不论绩效考核机制是否合理，既然已经这样了那就需要去适应。一直在做Network Application，早就知道ACE在业界中的名气，这回有理由找个时间好好挖掘一下ACE的思路，也为我的绩效目标增色啊^_^。

以上只是开个玩笑罢了。上周末去书店看到电子工业出版社再次出版的'C++网络编程卷一'，这套书的卷1以及卷2的英文电子版我早已有了，但是还是喜欢抱着纸板书看书的那种感觉，所以就顺便买了下来。翻看了一下，发现里面的内容恰恰是现在我所需要的，如果是前两年看这本书，理解起来肯定不会很透彻，因为那时的心中缺少的是恰恰是问题和困惑，没有了那些东西看书的效果也就大打折扣；反之如果作者的思路恰恰是把你扶上的正确的思维轨道，以帮助你解决了心中的那个结，你的收获就会是大大的。

记得前年的时候曾经下载过ACE并且尝试从源代码Build，结果是失败了，原因现在已经记不清了；这次重新下载ACE-5.5版本在Solaris 9上用G++ 3.2编译，居然顺利通过，其功劳应该归功于ACE的开发者之一Stephen D. Huston的'The ACE Programmers Guide'一书，而且从ACE自带文档中得知，ACE最先就是在Solaris上开发的。

Build过程：
1. 下载ACE的源码包；解包解压，一般你会在当前目录下获得一个名为'ACE_wrappers'的目录；
2. 设置ACE_ROOT环境变量；如我用的是csh，我就会在用户的HOME路径下的.cshrc中增加一个环境变量ACE_ROOT，比如：setenv ACE_ROOT '/export/home1/baim/ACE_wrappers'；
3. 切换路径到$ACE_ROOT/ace/下，创建config.h，在这个头文件中，我们需要做一件事，就是include一个你所在的编译平台的头文件，比如我是在Sun Solaris 9上编译的，我的config.h中的内容就是这样的：
//config.h
#include "config-sunos5.9.h"

不同的平台，包含的头文件不同，这些头文件也都在$ACE_ROOT/ace/下，你可以用'ls -l|grep config'来看看究竟有哪些config头文件，选择你所在平台对应的即可。

4. 切换到$ACE_ROOT/include/makeinclude下，创建一个叫'platform_macros.GNU'的文件，同样这里也有平台相关的一堆.GNU文件，我们只需在我们新建的platform_macros.GNU文件中包含对应文件即可。
如我用g++在Solaris 9上编译，我就该选择：platform_sunos5_g++.GNU
//platform_macros.GNU
include $(ACE_ROOT)/include/makeinclude/platform_sunos5_g++.GNU

这个文件里还可以放置make的编译选项，比如我要生成.a文件，我可以这么做：
//platform_macros.GNU
static_libs=1
include $(ACE_ROOT)/include/makeinclude/platform_sunos5_g++.GNU

5. 切换到$ACE_ROOT/ace/下，输入make命令执行即可。编译的过程是漫长的，大约1个小时，之后你就会发现在$ACE_ROOT/ace/下有libACE.so -> libACE.so.5.5.0*、libACE.so.5.5.0*和libACE.a出现了。

构建过程到此结束。

ACE的makefile没有.phony install，所以在你的ACE应用程序里可直接引用$(ACE_ROOT)/ace下面的头文件，直接链接$(ACE_ROOT)/ace下面的libACE.a库即可。

//HelloACE.cpp
#include "ace/Log_Msg.h"

void foo (void);

int ACE_TMAIN (int, ACE_TCHAR *[])
{
  ACE_TRACE(ACE_TEXT ("main"));

  ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IHi Mom\n")));
  foo();
  ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IGoodnight\n")));

  return 0;
}

void foo (void)
{
  ACE_TRACE (ACE_TEXT ("foo"));

  ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IHowdy Pardner\n")));
}

//编译
g++ -o HelloACE HelloACE.cpp -I$ACE_ROOT -I./ -L$ACE_ROOT/ace -lACE  -lsocket -ldl -lgen -lnsl -lposix4 -lthread

这里有几点注意事项：
1、如果libACE.so.5.5.0*和libACE.a都同时在$ACE_ROOT/ace下的话，上面的编译命令默认优先进行动态链接。也就是说编译出来的可执行程序HelloACE在运行的时候如果找不到libACE.so.5.5.0就会报错。
2、如果想进行静态链接的话，可以将$ACE_ROOT/ace下的libACE.so.5.5.0删除或者改名，这样在执行上面的编译命令后即是静态链接。
3、注意g++链接.a和.o时是有顺序的，g++从左到右读入目标文件或.a文件中的符号，如果靠右边的目标文件或者.a文件中没有靠左面的目标文件或者.a文件中的未定义的符号定义的话(或者白话一点说：右边没有左边想要的)，程序就会报错。比如我们把上述的编译命令改一下，改为：
g++ -o HelloACE -I$ACE_ROOT -I./ -L$ACE_ROOT/ace -lACE  -lsocket -ldl -lgen -lnsl -lposix4 -lthread HelloACE.cpp
执行命令后，会出现下面错误提示：

未定义                  文件中的
 符号                       在文件中
ACE_Log_Msg::log(ACE_Log_Priority, char const*, …)/var/tmp//ccBl9Q0L.o
ACE_Log_Msg::last_error_adapter()      /var/tmp//ccBl9Q0L.o
ACE_Log_Msg::conditional_set(char const*, int, int, int)/var/tmp//ccBl9Q0L.o
ACE_Log_Msg::instance()             /var/tmp//ccBl9Q0L.o
ld: 致命的: 符号参照错误. 没有输出被写入HelloACE
collect2: ld returned 1 exit status

实际上上面的命令g++ -o HelloACE -I$ACE_ROOT -I./ -L$ACE_ROOT/ace -lACE  -lsocket -ldl -lgen -lnsl -lposix4 -lthread HelloACE.cpp等价于下面两个命令：

g++ -c -I$ACE_ROOT -I./ HelloACE.cpp
g++ -o HelloACE -L$ACE_ROOT/ace -lACE  -lsocket -ldl -lgen -lnsl -lposix4 -lthread HelloACE.o

其实上面错误提示中的"/var/tmp//ccBl9Q0L.o"，其实就是一个匿名的HelloACE.o

另外在'The ACE Programmers Guide'一书中，作者给了个Makefile，如下：
BIN   = HelloACE
BUILD = $(VBIN)
SRC = $(addsuffix .cpp,$(BIN))
LIBS =
LDFLAGS = -L$(PROJ_ROOT)/lib
#—————————————————
#Include macros and targets
#—————————————————
include $(ACE_ROOT)/include/makeinclude/wrapper_macros.GNU
include $(ACE_ROOT)/include/makeinclude/macros.GNU
include $(ACE_ROOT)/include/makeinclude/rules.common.GNU
include $(ACE_ROOT)/include/makeinclude/rules.nonested.GNU
include $(ACE_ROOT)/include/makeinclude/rules.bin.GNU
include $(ACE_ROOT)/include/makeinclude/rules.local.GNU

直接用该Makefile会让你的build更简洁，另外还有支持多个.cpp文件的Makefile在那本书里，大家可以参考。

这个故事源于今天测试组测出的一个BUG，BUG被测试人员转给了我，故事便从这里开始了。

我们的系统是一个后台服务器程序，用C写的，运行在Solaris上，数据存储在数据库中，每次系统启动都要从数据库中读取配置数据。系统根据配置数据对输入的消息数据进行处理。今天的这个BUG现象就是对于一定的输入消息，系统根据配置数据的指导进行处理，结果得到的结果本应该是A，但是却得到了B。

首先咱抱着谨慎负责的态度，先从头到尾，再从尾到头检查自己的程序是否有漏洞或者疏忽大意之处，许久后，未发现问题，疑惑中，怎么经过我的程序这么一番处理，结果就是这样呢？

由于测试数据较简单，所以我对照着数据库中的数据，然后用输入消息数据在我脑子中根据程序的处理步骤人工处理了一次，终于发现了一处’不和谐的音符’。我发现数据库中一业务层配置表中的一字段的数据值有出入，赶忙打开数据库设计报告查看，一找一个准儿，问题就在这儿。

这个表中的这个字段的含义是’是否为默认项’，数据库设计报告中其值的定义是这样的：0 – 默认项；1 – 非默认项。首先我不去评论数据值设计是否合理，我们先来看看程序是如何处理的。
int is_default_item;
…..

if (is_default_item == 1) {
 /* 按照默认项处理 */
} else {
 /* 按照非默认项处理 */
}

看到这所有人都能看出问题所在了，没错，程序里想当然的以为’1′就是默认项，其他就是’非默认项’了。虽然问题找到了，但是我的心里却有了嘀咕，到底是谁错了，这个问题很显然有两个改法，一个是程序修改’1′->’0′；另一个是数据库修改，让1代表默认项。首先这里我要说我不是数据库设计的高手，可以说我自己没做过相关的数据库设计，数据库表中各字段取值设计有无经验可循我也不是很清楚。写到这可以把故事升华一下，升华成一个问题，也就是本篇的题目-0到底是’TRUE’还是’FALSE’?，这里的’TRUE’和’FALSE’并不仅仅代表真与假，而是代表更广义的含义，比如’TRUE’我们可以理解为’成功’、’正确’、’与预期目标一致’等；’FALSE’则可理解为’失败’、’错误’、’与预期目标不一致’等。

在UNIX上用C写过系统程序的人可能清楚Unix提供的API多以返回0代表调用成功，这就是一个典型的0表示’TRUE’的例子，这种返回值方式也被很多人用于程序设计中；在我们自己实现的底层库中，我们同样遵循了这样一种方式。还就我们上述的问题而言，数据库设计中’0′代表’默认项’是否就一定合理呢，相信也是见仁见智的问题；但是从程序角度，你认为：
if (is_default_item == 1) {
 /* 按照默认项处理 */
} else {
 /* 按照非默认项处理 */
}
更合逻辑还是
if (is_default_item == 0) {
 /* 按照默认项处理 */
} else {
 /* 按照非默认项处理 */
}
更合逻辑一些呢？起码我觉得第一种比较符合逻辑一些，代码可读性好些。当然如果按照下面的使用manifest constant的方式处理会比直接用literal constant更好些^_^，这样无论用0还是用1代表’默认项’起码从代码里都是逻辑通顺的，可读性好的。
#define DEFAULT_ITEM 1

if (is_default_item == DEFAULT_ITEM) {
 /* 按照默认项处理 */
} else {
 /* 按照非默认项处理 */
}

这个故事叙述到这就结束了，故事没有完，因为它在我们日常生活工作中还会时常发生，0是’TRUE’还是’FALSE’，把决定权留给大家^_^。