《跨平台软件开发——C&C++》
Write Portable Code，当初学C和C++时以为这很容易，真正想做一点东西时才发现这太难了。怪不得书中的作者说，ANSI C与C++是至今打算成为可移植语言的最不可移植的语言。
在前几天听IBM的讲座时，觉得无趣，便拿来这本书翻了一下。书名对我还是很有吸引力的，内容总结得也还可以。但没什么新鲜东西，一个多小时差不多就看完了，也没记住什么。可能这就是他说“可移植性是一种思考问题方式”的原因吧。该还掉它了，临了还是写点总结性的文字吧。
如果没有ANSI C&C++，恐怕也就没有出这本书的必要了吧。现在ANSI C&C++依然那么流行，无外乎是因为它在底层控制和性能上的优势。直接编译成本机代码的能力，也让它成为了嵌入式编程的钟爱。用的人多了，大家就喜欢定标准。ANSI，ISO，IEC……可惜标准的内容太多，实际中的支持也不完全，反正我是很少直接去看标准的（非很少，乃根本没有）。
作者从处理器、操作系统、编译器多个方面讨论了软件移植中出现的问题。
处理器的差别主要体现在存储要求（数据对齐、字节排序）、数据大小和格式和性能等几个方面。既然ANSI C&C++够底层，这些差别对它肯定会有影响了。
操作系统上的问题就跟多了。它的存在和可移植性本身就是一个悖论。每个OS提供的系统级API都是不可移植的，以至于像进程、线程之类的概念都不能被ANSI C&C++当作一级实体来看待。内存方面的问题更多，大小限制不可避免，映射方便了内存访问，却带来了兼容性的问题。还有内存的保护机制。提到这就不得不提下异常处理。虽然ANSI C&C++拥有规范的异常处理机制，但这与操作系统生成的命令完全无关，莫名其妙的程序中断也就不足为奇了。安全性的确是个大问题。想到病毒，就很容易想到windows的注册表。作为一种存储用户数据的方式，它在Linux和其他操作系统的实现又有很大的不同。Linux是保存在~/.MyApplication/preferences文件中，OS X则使用XML格式的首选项文件。还有些是文件系统差异导致的问题，也许你说这都不算什么，多加几次判断就行了。听说过“DLL地狱”没，这时你要判断的集合可就不是有限集了。共享库的语法差别比较大，但技术上相差不多。现在有一些方法对共享库进行了跟进一步的抽象，希望这能够让我们在这个“地狱级”的问题面前死而复生吧。
记得Scott Meyers提到过C++历史上最重要的5个软件：Cfront，GCC，Visual C++，STL和Boost类库。前三个才算是编译器吧，看过《C++资源之不完全导引》就知道其实还不只。其中占主导地位的编译器仍旧是由大公司设计开发的，虽然有标准存在，但技术保密和利益冲突仍会导致编译可移植上的问题。书上提到了存储格式和函数调用方面的移植难题。现在通用的解决方法应该是使用make和jam等构件工具，利用脚本语言在可移植性上的优势。
最近做了个网络相关的项目。如果使用最底层的套接字API，像BSD Socket API和WinSock，可移植性肯定又是大问题。还好有ACE，带来了很大的便利。此外，中间件还有CORBA、COM/DCOM、SOAP等，有必要去学一下。
总结下来，ANSI C&C++可移植性不好的原因，是因为它把系统级API和内存对象的布局直接暴露给了开发人员。既有优点，也是缺点。现在大家都有了很多的选择，看如何取舍了。
在前几天听IBM的讲座时，觉得无趣，便拿来这本书翻了一下。书名对我还是很有吸引力的，内容总结得也还可以。但没什么新鲜东西，一个多小时差不多就看完了，也没记住什么。可能这就是他说“可移植性是一种思考问题方式”的原因吧。该还掉它了，临了还是写点总结性的文字吧。
如果没有ANSI C&C++，恐怕也就没有出这本书的必要了吧。现在ANSI C&C++依然那么流行，无外乎是因为它在底层控制和性能上的优势。直接编译成本机代码的能力，也让它成为了嵌入式编程的钟爱。用的人多了，大家就喜欢定标准。ANSI，ISO，IEC……可惜标准的内容太多，实际中的支持也不完全，反正我是很少直接去看标准的（非很少，乃根本没有）。
作者从处理器、操作系统、编译器多个方面讨论了软件移植中出现的问题。
处理器的差别主要体现在存储要求（数据对齐、字节排序）、数据大小和格式和性能等几个方面。既然ANSI C&C++够底层，这些差别对它肯定会有影响了。
操作系统上的问题就跟多了。它的存在和可移植性本身就是一个悖论。每个OS提供的系统级API都是不可移植的，以至于像进程、线程之类的概念都不能被ANSI C&C++当作一级实体来看待。内存方面的问题更多，大小限制不可避免，映射方便了内存访问，却带来了兼容性的问题。还有内存的保护机制。提到这就不得不提下异常处理。虽然ANSI C&C++拥有规范的异常处理机制，但这与操作系统生成的命令完全无关，莫名其妙的程序中断也就不足为奇了。安全性的确是个大问题。想到病毒，就很容易想到windows的注册表。作为一种存储用户数据的方式，它在Linux和其他操作系统的实现又有很大的不同。Linux是保存在~/.MyApplication/preferences文件中，OS X则使用XML格式的首选项文件。还有些是文件系统差异导致的问题，也许你说这都不算什么，多加几次判断就行了。听说过“DLL地狱”没，这时你要判断的集合可就不是有限集了。共享库的语法差别比较大，但技术上相差不多。现在有一些方法对共享库进行了跟进一步的抽象，希望这能够让我们在这个“地狱级”的问题面前死而复生吧。
记得Scott Meyers提到过C++历史上最重要的5个软件：Cfront，GCC，Visual C++，STL和Boost类库。前三个才算是编译器吧，看过《C++资源之不完全导引》就知道其实还不只。其中占主导地位的编译器仍旧是由大公司设计开发的，虽然有标准存在，但技术保密和利益冲突仍会导致编译可移植上的问题。书上提到了存储格式和函数调用方面的移植难题。现在通用的解决方法应该是使用make和jam等构件工具，利用脚本语言在可移植性上的优势。
最近做了个网络相关的项目。如果使用最底层的套接字API，像BSD Socket API和WinSock，可移植性肯定又是大问题。还好有ACE，带来了很大的便利。此外，中间件还有CORBA、COM/DCOM、SOAP等，有必要去学一下。
总结下来，ANSI C&C++可移植性不好的原因，是因为它把系统级API和内存对象的布局直接暴露给了开发人员。既有优点，也是缺点。现在大家都有了很多的选择，看如何取舍了。
