编写可移植C/C++程序的要点
1.分层设计，隔离平台相关的代码。就像可测试性一样，可移植性也要从设计抓起。一般来说，最上层和最下层都不具有良好的可移植性。最上层是GUI，大多数GUI都不是跨平台的，如Win32 SDK和MFC。最下层是操作系统API，大多部分操作系统API都是专用的。
如果这两层的代码散布在整个软件中，那么这个软件的可植性将非常的差，这是不言自明的。那么如何避免这种情况呢？当然是分层设计了：
最底层采用Adapter模式，把不同操作系统的API封装成一套统一的接口。至于封装成类还是封装成函数，要看你采用的C还是C++写的程序了。这看起来很简单，其实不尽然（看完整篇文章后你会明白的），它将耗去你大量的时间去编写代码，去测试它们。采用现存的程序库，是明智的做法，有很多这样的库，比如，C库有glib（GNOME的基础类），C++库有ACE(ADAPTIVE Communication Environment)等等，在开发第一个平台时就采用这些库，可以大大减少移植的工作量。
最上层采用MVC模型，分离界面表现与内部逻辑代码。把大部分代码放到内部逻辑里面，界面仅仅是显示和接收输入，即使要换一套GUI，工作量也不大。这同时也是提高可测试性的手段之一，当然还有其它一些附加好处。所以即使你采用QT或者GTK+等跨平台的GUI设计软件界面，分离界面表现与内部逻辑也是非常有用的。
若做到了以上两点，程序的可移植性基本上有保障了，其它的只是技术细节问题。
2.事先熟悉各目标平台，合理抽象底层功能。这一点是建立在分层设计之上的，大多数底层函数，像线程、同步机制和IPC机制等等，不同平台提供的函数，几乎是一一对应的，封装这些函数很简单，实现Adapter的工作几乎只是体力活。然而，对于一些比较特殊的应用，如图形组件本身，就拿GTK+ 来说吧，基于X Window的功能和基于Win32的功能，两者差巨大，除了窗口、事件等基本概念外，几乎没有什么相同的，如果不事先了解各个平台的特性，在设计时就精心考虑的话，抽象出来的抽口在另外一个平台几乎无法实现。
3.尽量使用标准C/C++函数。大多数平台都会实现POSIX(Portable Operating System Interface)规定的函数，但这些函数较原生(Native) 函数来说，性能上的表现可能较次一些，用起来也不如原生函数方便。但是，最好不要贪图这种便宜而使用原生函数函数，否则搬起的石头最终会轧到自己的脚。比如，文件操作就用fopen之类的函数，而不要用CreateFile之类的函数等。
4.尽量不要使用C/C++新标准里出现的特性
相关文档：
Flex 和C++ 之间传输结构体数据
一直想试验用结构体传数据
但是Flex 和C++ 的类型所占的字节数有时不一样
如int 在C++中站2个字节，而在Flex中占4个字节。
转换比较麻烦。
最后决定用XML进行传输
然后两边都加一个XML 解析和封装类。
C++ 端使用的tinyXML 类
Flex直接使用自己带的 E4X 类
Flex代码如下
&nb ......
越界是最难查的，注意memcpy strcpy,strncpy这些函数使用前一定要检查边界
特别是你提供函数给别人用时，你的函数中用到了这些东西，一定要检查别人传给你的指针的
边界
2、变量初始化
这种问题要养成好习惯，否则出来偶然性问题，非常难查
3、多线程指针管理
在多线程环境下使用指针时，最好采用引用� ......
题目：在屏幕上画一个矩形
要求：每按一次键盘，该矩形转动45度。矩形的大小和转动的方向有键盘输入，并将输入的数据送文件保存，按回车键程序结束。（功能延伸：改变数据文件的内容后，再根据数据文件里的数据绘制矩形）
......
1.fopen()
fopen的原型是：FILE *fopen(const char
*filename,const char
*mode)，fopen实现三个功能：为使用而打开一个流，把一个文件和此流相连接，给此流返回一个FILR指针。
参数filename指向要打开的文件名，mode表示打开状态的字符串，其
取值如下：
字符串 含义
"r" 以只读方式打开 ......
在C语言中，escape的符号很好用，
比如
"中国一定强"
这个字串可以写成：
"\x4E2D\x56FD\x4E00\x5B9A\x5F3A"
用字元编码编写程序，在其他不同语言的windows运作时，比较不会有问题。
（我尽量不想在程序中写入中文）
但是vb如果全部要用字元编码写的话，就会很麻烦而且一个一个都要手写成：
ChrW(&H4E2D) ......
