sprintf至C语言流传至今，经久不衰，虽然microsoft好心提供sprintf_s，并发出C4996的尖叫，我个人是比较不接这个领子。 sprintf安全问题一直被大家质疑，但我觉的出现了安全的问题是设计上的缺陷，正如线程死锁也是设计上的缺陷，一个需要杀死线程的程序绝对不是一个合 格的程序。
lexical_cast是boost的成员之一，因为文件比较短，源码走马观花的看过一遍，内部使用的是stream，不过lexical_cast仅仅是个转换，其出现用于代替atoi，这里顺便带过。
format是boost提供的用于格式化的库，我才疏学浅也没时间分析源码，只知道使用方法。有兴趣的可以看看，一定会有不少收获，发出C++原来还能这样用的感叹。
测试
下面对该3各具特色的函数进行效率上的测试。
测试环境：赛扬D2.66G 内存512M，测试状态为日常应用状态（即运行了一些程序）VC8.0
测试程序很简单，简单的循环
for(int i=0;i<1000000;i++)
{
command;
}
各执行100万次后得出下表
commandRelease(ns) Debug(ns)
sprintf(buf,\"%d\",3);289769 451770
lexical_cast<string>(3)1165520402.22%218024204826.00%
format(\"%1%\")%3;140060004833.51%13364920029583.46%
sprintf(buf,\"%d %s\",3,\"Hello\");527948 828527
format(\"%1% %2%\")%3%\"Hello\";187453003550.60%17815380021502.47%
和官方性的性能测式有些出入，诂计是我赛扬的原因且运行了一些程序。
意料之中，sprintf因其没啥\"负担\"效率手当其冲，功能最复杂的boost.format居于最后。lexical_cast虽然花了400%的时间，相对值虽然大，但绝对值还是可以接受的。
总结
在效率第一的情况下如内核，核心算法，反朴归真是最佳的选择，用c命令代替c++命令等等。
lexical_cast可以用在一般的应用，但如前文所说仅仅单个的格式转换。
format的速度约为15ns/条，比起sprintf着实笨拙，但在高速的计算机面前，一般应用也是绝对可以接受的，虽然多花了三四十倍的时间，但因其具备完全替代sprintf的功能且有过之而无不及，也有一立足之地。
