用string_builder_t高效格式化字符串，源码已上传

烽驿2009开源实时通信平台 源码获取：svn checkout http://fy2009.googlecode.com/svn/trunk/ fy2009-read-only

 

字符串拼装或格式化是软件开发中经常使用的功能。对于通信软件，随着各类文本协议（如基于HTTP或XML）的日趋流行，这种需求更普遍。多数编程语言也都提供了这类服务，C中的可用方法主要是sprintf,C++中既可以继续用C的方法，也可以用C++的标准对象stringstream,当然，如果是VC，还用CString等更多选择。下面对sprintf, stringstream和笔者实现的string_builder_t进行一个性能测试，该测试在Linux下完成，测试将9个字符串片断和6个整数2个浮点数拼装到一起，共测试1000次，不同方法用时如下：
sprintf: 64ms
stringstream: 450ms
string_builder_t: 220ms（利用prealloc预分配足够大的内存，性能将提高到190ms, 再打开eUNCPY_STR选项，则只需：155ms）
由上述结果可见，最古老最简单的sprintf性能最高，比stringstream高出6倍，比笔者的实现也高出1.4倍。这足以让怀旧的人们深受鼓舞，同时开始质疑笔者的string_builder_t还有什么存在的必要？更何谈高性能？稍安勿躁，其实，sprintf并非总能成为后两者的替代物，其一，它有所有C字符串函数所共有的缺陷－－必需由调用者预分配结果Buffer的尺寸，如笔者在前面有关“自描述缓冲区”的博文中所描述的那样，这在很多时候对调用者是苛刻的，不适当的；其二，当你需要将成百上千个片断拼装起来的时候，sprintf会让人发疯，而这在将非文本内容格式化成文本协议所要求的格式时经常遇到，而这时才是stringstream和string_builder_t登台的时刻，因此，sprintf和stringstream, string_builder_t并不属于同一种“生物”，不完全具有可比性，真正的对手是后面两个，所幸，在他们的角逐中，笔者的string_builder_t胜出，性能高出约1－2倍。
在用string_builder_t拼装字符串时，你可以用"<<"运算符去串联需要拼装的片断，但这时实际拼装并没有发生，这些片断只是被记录下来，直到最后调用build方法时，才真正将被一次拼接成形，此时，string_builder_t已经知道结果串的长度，结合使用前述“自描述缓冲区”，string_builder_t最多为结果串分配一次内存，且只需Copy一次。因此，其在大量级的字符串拼装中有着上佳表现。
当然，你仍然不应忘了上面的测试结论：如果你确信可以在现在和将来满足你的要求，sprintf仍然是你的上选。否则，string_builder_t不应该被忽视，因为它比stringstream快1－2倍。