最近收到客户的一个需求，要求我们将产品的系统配置数据和业务配置数据定期导出备份，以防万一数据库宕掉后可以用来"救火"。产品从起初0.1版本就一直延续着一种"section-key-value"的配置文件方式，同时我们也有可复用的库来完成配置数据的读取，可是在长期的使用过程中我们发现的不少问题，特别是在存储多样化的业务数据的时候，这样的配置方式带来维护上的很大不便。

"section-key-value"这样的配置文件方式或者类似于环境变量似的配置文件方式用来做系统自己的配置可以说既简单又实用，像著名的Apache服务器、版本控制系统svn等都是采用这种方式。在我们产品的初期，那时的业务相对简单，采用这样的一种配置方式还算是合适的。但随着业务复杂度的上升，种类繁多的业务数据的出现，这种配置方式的弊端渐渐显现。

最大的弊端就是"同步"问题。每当我们的产品升级时，我们一般都会先升级数据库的配置，然后再同步文档，最后同步配置文件以及相关读取代码。如果工作量较大，升级工期较紧的时候，常常忽略了将新增或修改的配置同步到配置文件；这样累积到一定时间之后，除了花费大力气去"补"，别无它法。另外一个弊端就是上面提到的那个问题：从数据库导出配置文件始终是那么"别扭"，曾经尝试过使用脚本导出、Java程序导出，但是始终不能让人很满意，挖掘一下深层原因：配置文件和数据库表设计"不搭调"。业务数据千变万化，导致从数据库导出配置文件的逻辑甚是复杂，维护起来十分不便；而且像"section-key-value"这样的结构，数据库中由于没有section的字串，导致这些section必须"写死"在代码中。

不错，我们在寻找替代品，目标锁定在xml。曾经在2005年做的一个项目中尝试过使用xml作为配置数据，取得了很好的效果。记得当时参考Ant的build.xml的配置方式，顺利解决了一个"自动化处理"的配置设计，那应该是部门第一次采用xml做为后台C实现的系统的配置文件。也是自那以后，我感受到了xml的强大描述能力。xml在Java世界可以说占据了大部江山，从DB导出数据到xml可以说轻而易举，这又恰好解决了本篇所提到的"同步"难题。

坐在公司的Bus上，大致想出了如下xml作为配置文件的好处：
1) 与DB表几乎无缝转换，方便导入导出；
2) 作为元语言，其描述能力毋庸置疑；
3) 在Java世界几乎是配置文件的首选或者说是标准也不过分，选择标准的，总会被支持的很好；
4) 诸多开源工具支持对XML的读写甚至支持加密；
5) 文本形式，方便浏览和信息查找(grep or find均可派得上用场)，这也符合Unix编程艺术(TAOUP)作者在书中阐述的一个原则-尽量文本化。
6) DTD或schema验证，自动验证格式是否OK。
… …

当然缺点也是有的：
1) 如果不加密，是明文，保存账户、密码等数据时要小心，当然这也是文本配置的通病；
2) 如果设计不当，会导致"xml地狱"，xml太多也太烦，很多Java世界的产品就有此弊病。

大致在心里估算了一下，读取xml承载的配置与读取传统的配置的代码量没有太大出入，但是如果xml设计的足够精致，后期的维护工作将大为减少。xml配置改造工作看来势在必行了。

早上在写代码时遇到这样一个问题：即如何在一个拥有多行的宏定义中做注释？，这里把方法演化的过程贴出来，可能对某些朋友有些借鉴意义。

宏定义高深莫测，而且是比较细节的东西，详细说明请参见"C参考手册"之类的书籍。

在我的代码中，我大致要做这样一个简单的事情：printf("%s%s%s\n", "hello", "macro", "yeah!"); "%s%s%s\n"这个字符串中每一项输出都有一定的含义，而且在真实代码里，这个串中的输出项可不止3个，所以一个直接的想法就是将其定义为一个宏。

#define STR_OUTPUT_FORMAT_V0  "%s%s%s\n"
printf(STR_OUTPUT_FORMAT_V0, "hello ", "macro, ", "yeah!");
程序输出：hello macro, yeah!

由于真实代码中这个串很长，所以打算美化一下格式，定义成下面的样子：
#define STR_OUTPUT_FORMAT_V1  "%s\
                               %s\
                               %s\n"
printf(STR_OUTPUT_FORMAT_V1, "hello ", "macro, ", "yeah!");
程序输出：hello                                macro,                                yeah!

这样的定义显然不对，也在我意料之中，续行符将空格也续到格式串中了，导致输出的结果中带有大量空格。

改进一下，利用C语言的字符串自动连接语法。
#define STR_OUTPUT_FORMAT_V2  "%s"\
                              "%s"\
                              "%s\n"
printf(STR_OUTPUT_FORMAT_V2, "hello ", "macro, ", "yeah!");
程序输出：hello macro, yeah!

现在的问题是如何在这样一个多行的宏定义里加入注释，字段含义特殊，加上注释有利于以后维护以及别人阅读你的代码，否则一堆%s%s，让人看了就头痛。先这么加试试：
#define STR_OUTPUT_FORMAT_E1  "%s"\   /* comment1 */
                              "%s"\   /* comment2 */
                              "%s\n"  /* comment3 */
printf(STR_OUTPUT_FORMAT_E1, "hello ", "macro, ", "yeah!");
我们得到的结果：编译错误。
通过gcc -E 选项我们看到，宏替换后的代码:
                              "%s"\
                              "%s\n"
int main() {
        printf("%s"\, "hello ", "macro, ", "yeah!");
}

由于没有续行符在注释前面，所以宏定义的后两行实际上并没有被包含在宏定义中，就像没有暂住证的人一样，被GCC这个"警察"逮个正着。

继续改进：
#define STR_OUTPUT_FORMAT_V3  "%s"   /* comment1 */ \
                              "%s"   /* comment2 */ \
                              "%s\n"  /* comment3 */
printf(STR_OUTPUT_FORMAT_V3, "hello ", "macro, ", "yeah!");
程序输出：hello macro, yeah!
显然预编译器忽略宏定义中的注释以及空格，STR_OUTPUT_FORMAT_V3就完全符合我的要求了。

当然，很多人不建议使用宏，特别是C++的Fans，宏也的确有很多弊端，这里也有替代方法：
const char *str_output_format = "%s"    /* comment1 */
                                 "%s"    /* comment2 */
                                 "%s\n"; /* comment3 */
printf(str_output_format, "hello ", "macro, ", "yeah!");
程序输出：hello macro, yeah!

用一个字符串变量代替格式宏，还可以避免上述由于在宏中做注释带来的一系列问题。