vc转linux环境,将VC程序移植到LINUX系统

最新推荐文章于 2022-08-27 10:33:09 发布

weixin_39967096

最新推荐文章于 2022-08-27 10:33:09 发布

阅读量279

点赞数

文章标签： vc转linux环境

【IT168 技术文档】

有时我需要制作LINUX与WINDOWS下都可以运行的程序。在一般情况下，我会选择在WINDOWS平台下完成初始的开发。因为VC提供的图形化的编辑与调试界面的确较GCC要高产得多。在完成了测试之后，就开始把它向LINUX移植，移植的过程会有一些需要注意的地方。下面就是我的一些心得。

文件名

由于ext2文件系统对文件名是大小写敏感的，当你在这种文件系统上进行编译的时候，源文件中出现的#include 语句必须小心了。因为在VC环境下，由IDE自动生成的#include 语句，其中的文件名全部是小写的。所以，你需要在一开始就注意这个问题，严格的使用大小写敏感的文件名格式，避免在LINUX下编译时出现找不到头文件的错误。

数据类型

千万不要使用VC独有的数据类型，象__int16, __int32 和__int64 等等，你无法保证其它的编译器能否支持它们。特别是__int64，它确实简化了编程工作，但是当你的逻辑里充满了这样的数据类型的时候，改动就变得无比困难了。还有一个问题就是，我们经常在VC中使用WORD,DWORD，INT，UINT这样的扩展数据类型，不直接使用编译器的数据类型有助于提高在不同平台之间的可移植性。但是LINUX下没有定义这样的类型啊？其实只需要将windows.h和basetypes.h中对这些数据进行定义的语句复制到一个头文件中，再在linux下包括进来就行了。

关键字

关键字是比较好处理的东西，凡是VC中带两个下划线的关键字，比方__asm都是VC独有的。尽量不使用它们，如果实在无法避免，就用#ifdef 和#endif为LINUX和WINDOWS编写两个版本。

MAKEFILE的编写

你可以先用VC导出一个makefile，然后对其进行修改，但我倾向于从中拷贝出一段来生成GCC的makefile，比起手工编写要快许多。

程序设计结构

这绝对是移植过程中问题最大的一个部分。应用程序难免要用到操作系统的服务，如果完全使用标准的C/C++编写，这将不是一个问题，但是当我们使用到多进/线程，管道，或者对WINDOWS图形界面的程序进行移植的时候，这个问题就变得突出了。我们应当从设计上就为程序的移植打好基础。

解决这个问题首先必须搞清楚应用程序的逻辑模块。对于这个模块必须使用标准的C/C++进行编写。同时将应用程序使用的线程数最小化，线程越多越难移植。将输入输出模块独立出来。最后划分出控制模块，这个模块与用户进行交互。

上面所讲是我在处理一般的，面向桌面用户的一些程序的大的原则。

下面是寻找应用程序进线程单元具体的方法，见图1：

图1：基本程序模块

这种图似乎随处可见，但是真正严格遵循了的人却是很少的。

同常情况下，核心模块只需要一个进线程，如果你的核心模块需要两个以上的进线程，则说明还需要更细的划分，直至一个模块对应一个进线程。

这个图中的箭头意义重大。在画完模块图以后，就是分清这些箭头是同步的还是异步的。比方核心模块与输入模块之间，是否需要核心模块等待输入模块将数据读取完毕然后才能运行？如果答案为“是”，那么你可以将这两个模块合并到同一个线程中来。(如图2)如果被划分到同一个进线程块中来的两个模块又与第三个模块是同步的关系，那么就可以把第三个模块也组合到这个进线程单位中来。直到每一个模块都被包含在了一个进线程单位中。

图2：划分进线程单位后

值得注意的是，如果其中一个模块被包含在了两个以上的进线程单位中或者没有被包含在任何进线程单位中，则你的划分一定是有错的。

在通常的情况下，应用程序的进线程单位的划分最后会变成图2的形式。因为控制模块往往需要与用户同步，而不是核心模块，所以它需要一个单独的进/线程(通常是线程)。为了提高性能，输出模块也往往与逻辑模块异步工作，必须用不同的进线程来完成。完成了上面的图，数一数虚线框，就是最合适的进线程数目了。

进线程的实现是操作系统相关的。我们可以将进线程这个载体与它搭载的逻辑分离开来。我的经验是：视上图中划分的每一个进线程单位为一个同步实体。这个实体可以封装在这样的一个几乎所有多任务操作系统都支持的抽象类里：

classCSyn

...{

virtualInit()=0;//初始化virtualCreate(BOOL Suspended)=0;//创建virtualRun()=0;//运行virtualSuspend()=0;//挂起virtualKill()=0;//杀死virtualResume()=0;//取消挂起状态}

所有的同步实体都必须由这个类派生。同步实体可以创建新的同步实体，并应该负责管理它们，打个比方，同步实体必须在自己退出之前调用所有它创建的同步实体的Kill函数。

你不一定非要使用上面的类，但一定要遵循上面的原则，它可以保证你在移植多进线程程序的时候逻辑清晰。

进线程之间的通讯是第二个棘手的问题。同步实体之间的通讯也应当用一个类来进行抽象。这样在移植的时候，我们只需要对这个类进行修改。同时，通讯的数据最好使用流的方式，这样我们可以将通讯类设计成象cout与cin这样的类。同步实体所有的输入数据都应该来自通讯类，所有的输出数据也应该到通讯类那里去。

输出模块的设计原则与上面的并无二致，尽量多的使用函数过程和类来进行抽象能够进一步的降低移植难度。

最后需要说明的是，上面的设计可能还需要添加其它的模块才能完成真正的应用程序。比如在WINDOWS平台下，我们可能需要在输出模块和控制模块的外延添加上窗口控制模块来完成一个完整的图形化WINDOWS程序，如果把窗口控制模块改成一个批处理文件的解析模块，我们可以做成LINUX下的一个批处理执行的应用程序。良好的模块设计能够让这种替换成为可能。可以说，一个移植性良好的程序，其可扩展性也一定是非常好的。

上面的例子非常简单，在实际的设计过程中，模块的划分会复杂得多。动手移植一个WINDOWS应用程序会让你深有体会。