由TCHAR引发的不同语言对字符串设计思路的随想

如果用了两个第三方的库，一个使用TCHAR，另一个只是传统的char（其实这种库最常见），恶梦就开始了，代码中将充斥了#ifdef _UNICODE和各种恶心的转换函数（既然转换，还必须得考虑locale，比如到处都是的setlocale(LC_ALL, "")和setlocale(LC_ALL, "C")）。

 

现在的语言，支持Unicode是大趋势。貌似主要两个流派。一个是Java和Python那样，语言本身的字符串都统一编码，这样程序员在这方面没什么工作量，但是因为进出程序的字符串都得自动转换，效率上有开销；另一个是Ruby 1.9这种，允许各种编码的字符串，且字符串类能够自身负责记录编码和转换编码，它的字符串更像是Byte Stream。当然，我比较喜欢后者。不过Ruby 1.9让我最头痛的问题还是老的库和1.9这个新特性的兼容性（你尝试下ROR+Ruby 1.9），但是依靠Ruby活跃的社区，应该会慢慢好转。C/C++的字符串（我只是指char*和wchar*）就是一种正宗的Byte Stream，但可惜的就是它就是一个半身不遂生活不能自理的16进制烂泥，而不是一个类。TCHAR的出现明显是想用宏来模拟Java那种字符串统一编码的机制，可惜还是历史包袱太重（而且不像Ruby那么容易改进），遇到我这种情况，真的显得太笨拙了。