跨平台C++程序开发系列文章

zjzfb

/*
********************************************************************************
*
* 作者：祝飞
* 邮件：zhufei@wawton.com
* MSN： zhufei@wawton.com
* 出处：http://zhufei1980.spaces.live.co ... 29BCEF27B!121.entry
*
* 本系列文章采用类BSD协议发布：
*     无论修改与否，你都可以进行任何目的的转发，甚至于直接销售，只需要满足以下条件：
*     1. 包含作者信息（作者、邮件、MSN、出处、协议）
*     2. 未获得授权情况下，请勿使用作者信息进行任何目的的推广活动
* 违反协议的情况下，作者保留所有权利。
*
********************************************************************************
*/

总概
    跨平台C++程序开发，顾名思义，一份相同的代码，在不同的平台编译，在不同的平台运行。
    所谓的跨平台，一般意义上指Windows和Unix-like平台；
    需要跨平台的程序，一般从Unix-like平台跨越到Windows平台，需要更多平台的展示及更低廉的解决方案；
    而从计算机的方展史来看，先有Unix-like系统，后有Windows平台，Windows平台的许多系统接口参考了Unix-like系统接口；
    所以，现有的跨平台解决方案，一般都偏向Unix接口；
    要进行跨平台开发，建议先打好Unix-like系统的C/C++编程基础。

总概
    跨平台C++程序开发，顾名思义，一份相同的代码，在不同的平台编译，在不同的平台运行。
    所谓的跨平台，一般意义上指Windows和Unix-like平台；
    需要跨平台的程序，一般从Unix-like平台跨越到Windows平台，需要更多平台的展示及更低廉的解决方案；
    而从计算机的方展史来看，先有Unix-like系统，后有Windows平台，Windows平台的许多系统接口参考了Unix-like系统接口；
    所以，现有的跨平台解决方案，一般都偏向Unix接口；
    要进行跨平台开发，建议先打好Unix-like系统的C/C++编程基础。

发布地址：
http://zhufei1980.spaces.live.com/

C++循序渐进学习之书籍推荐

目录
    1.  跨平台C++程序开发系列之一 开发工具选择
    2.  跨平台C++程序开发系列之二 MPC多平台编译工程文件生成工具，附实例
    3.  跨平台C++程序开发系列之三 CppUnit自动测试工具，附实例
    4.  跨平台C++程序开发系列之四 Doxygen接口文档生成，附实例
    5.  跨平台C++程序开发系列之五 ACE跨平台工具库引介
    6.  跨平台C++程序开发系列之六 DLL/so动态库开发基础，附实例
    7.  跨平台C++程序开发系列之七 DLL/so动态库开发进阶，附实例
    8.  跨平台C++程序开发系列之八 DLL/so动态库开发高阶之COM_CORBA本质，附实例
    9.  跨平台C++程序开发系列之九 多厂家支持数据库操作接口
    10. 跨平台C++程序开发系列之十 GUI开发工具的选择
    11. 跨平台C++程序开发系列之十一 C与C++的选择与平衡
    12. 跨平台C++程序开发系列之十二 基于管理和预分配池的多进程多线程服务器端程序方案
    13. 跨平台C++程序开发系列之十三 开发架构模式的选择，CMM与XP的混合

注：
    跨平台C/C++程序开发的条件宏基础
    #ifdef WIN32
        ...
/*
    #elif defined( SUNOS ) // 更多平台的定义
        ...
*/
    #else //!WIN32
        ...
    #endif //end WIN32 + !WIN32

说明：
    连载模式，慢慢补充，8月份完成上述文章的初稿

同时想与大家共同探讨以下问题：
    1. Linux软件开发，在大量动态库的情况下，避免root权限、避免依赖地狱，就是如同Windows软件，将冲突限定于自己的程序目录
        我个人所经历的Unix-like动态库地狱，一个体会是依赖，但更重要的一个体会是冲突：
            依赖：只好不停地到网上搜索各类软件
            冲突：辛辛苦苦下载了制定版本的软件，结果发现与现有软件冲突，无法使用，最终放弃
        放弃的软件多了，也就放弃了平台，很无奈，却是事实

        从来都不是系统的问题：系统接口几十年如一日，不可能说变就变，而且如果变了，如何保证原先系统的健壮性
        也从来不是用户的问题：用户使用现有系统，目的就是方便，当操作复杂度和系统冲突成本高于直接价格优惠时，用户有权利选择另外的系统
        有问题的是开发软件系统的人：怎么没有找到在现有系统上满足用户需求的解决方案？

    关于这个方案，有了个初步解决方式，不过还有很多问题：到时会发布开源程序，欢迎大家届时下载共同探讨。

[ 本帖最后由 zjzfb 于 2009-8-22 17:42 编辑 ]

OwnWaterloo

嘿， 前几天搜这方面的工具， 没搜到这个。
MPC这名字取得不太好。。。。   相同词条太多。。。。

试试先

zjzfb

原帖由 OwnWaterloo 于 2009-8-18 14:09 发表
嘿， 前几天搜这方面的工具， 没搜到这个。
MPC这名字取得不太好。。。。   相同词条太多。。。。

试试先

也才今天更新发布的，现在重新排布了下
麻雀虽小，五脏俱全：不过如果是版本发布，或者用到其他版本库，可能需要些许更改
有需要的话可以发邮件给我，尽量提供一些建议参考

GodPig

这个要关注一下~~~

群雄逐鹿

第10章：GUI开发工具的选择

这个期待LZ表达一下看法。满足下面这些条件的GUI, 目前还没有发现：
1. 原生的GUI代码
2. 在某个平台像某个平台
3. 轻量级的包装，最好是header only或很小的library
4. 基于stl like的，比如有 iterator 可以遍历窗口
5. 支持属性操作

这里有列出大部分的GUI库，并且一直在更新
http://www.thefreecountry.com/sourcecode/gui.shtml

yugliu

我才看第一篇“跨平台C++程序开发系列之一 开发工具选择” ，就发现一个地方写错了。

1. Windows平台采用gcc/gdb，基本不可能用来进行商业软件开发（Code::Blocks支持VC的原生态，可惜不能用来调试）

“Code::Blocks支持VC的原生态，可惜不能用来调试”  -- 这句。 CB支持 CDB，可以调试。

其他的还有许多地方待商榷，权作参考

zjzfb

原帖由 yugliu 于 2009-8-19 09:50 发表
我才看第一篇“跨平台C++程序开发系列之一 开发工具选择” ，就发现一个地方写错了。

1. Windows平台采用gcc/gdb，基本不可能用来进行商业软件开发（Code::Blocks支持VC的原生态，可惜不能用来调试）

“C ...

每个人使用各类工具，肯定会有偏颇之处
写的系列文章之类的，和每个人所走的路相关，有些人合适，也有些人不合适，仅提供参考而已
同时欢迎共同探讨各类问题和缺陷，会在文章一修改这个问题的

刚刚搜索了把CodeBlocks+CDB，条目很少，但至少看到
1. 我在使用code::blocks，在调试visual c++ 2005时报告调试器没有找到，code::blocks默认的vc2005调试器是cdb.exe，但是vc目录下没有这个。
2. Also supports MS CDB (not fully featured)。

同时，在Code::Blocks官方论坛里的一个讨论帖：Unable to debug with Visual C++ 2008 Express
http://forums.codeblocks.org/index.php?topic=8454.0
看了一下，至少一些人放弃了

这里再补充一下自己对典型Unix-like平台软件的体会吧（Code::Blocks可以归属于这一类）：
1. 依赖软件（库）地狱
    基本上可以把一个用户给搞崩溃，或者引入更多的冲突。
    我现在配置安装Linux系统，很强调系统一致性，就是宁可用低版本的系统，不打任何系统补丁，也要保证所有软件的版本一致。
2. 没有良好的说明
    就如Code::Blocks，基本上没有人能够看到使用VC编译器时关于CDB的提示；结果就是，大多数人像我一样，用原生VC，结果直观地发现没有调试器可用，然后放弃。
    对比微软的免费版VC2005 Express，至少人家在显眼的地方提示没有PlatformSDK，需要如何按步骤操作。

至于世界上为什么那么多人选择Windows平台
相信很大一部分和我类似，只是需要一个可用的软件，不需要大投入，不需要看形形色色的文档
所需要的仅仅是打开软件，高效地完成工作，让自己关注于业务领域
这才是Linux图形化发展的一个重要参介点

[ 本帖最后由 zjzfb 于 2009-8-19 12:32 编辑 ]

anders0913

mark，学习中~~

zjzfb

原帖由 群雄逐鹿 于 2009-8-19 08:58 发表
第10章：GUI开发工具的选择

这个期待LZ表达一下看法。满足下面这些条件的GUI, 目前还没有发现：
1. 原生的GUI代码
2. 在某个平台像某个平台
3. 轻量级的包装，最好是header only或很小的library
4. 基于 ...

没有那么多，只会选择式地评点下QT+wxWidgets，基于C++，直接忽略X11和GTK

1. 原生的GUI代码 - 自定义规则的代码接口？QT做到这一点了，wxWidgets的话是类MFC规则
2. 在某个平台像某个平台 - wxWidgets基本做到了，所谓的Platform Native
3. 轻量级的包装，最好是header only或很小的library - 这个没考虑，基本只考虑PC应用，不同的平台接口差异太大，只用头文件造成代码复杂度剧升，同时内联造成最终程序过大
4. 基于stl like的，比如有 iterator 可以遍历窗口 - QT/wxWidgets都已实现这类功能
5. 支持属性操作 - QT/wxWidgets都已实现这类功能

OwnWaterloo

再顶一下， 支持lz的工作~~~

原帖由 zjzfb 于 2009-8-18 13:42 发表
1. Linux软件开发，在大量动态库的情况下，避免root权限、避免依赖地狱，就是如同Windows软件，将冲突限定于自己的程序目录

关于这个问题。 "冲突限定于自己的程序目录"的意思是将所有需要的dll都拷贝到exe同目录下？
这样……  和直接使用静态链接有什么区别吗？
也还是有一点区别的， 理论上来说， 替换（或者说升级）的可能性依然存在， exe的发布者， 可以测试该exe所依赖的dll的高版本是否会产生冲突， 并提出可以使用的dll版本的组合，让用户自由选择dllA的x版本、dllB的y版本。
但有多少公司真这样做了？  而且就方便来说， 还是整体打包下载较好。

而且， dll的另一个优势： 共享代码、减少内存使用，  肯定是要被抹杀了。


我觉得吧， 如果某个库打算做成dll的形式， “对以前版本的兼容性”就是一种义务。
Windows下诸多API， 要么操作的是HANLDE, 要么是一个incomplete的指针。
一旦出现定义完整的结构体， 第1个成员必定是size， 并且使用前必须 size = sizeof(S);
这不是没有道理的。

如果大部分API都能做到对以前版本兼容， 具体的说， 是“继续满足以前版本与客户代码之间的契约”， 那很多问题就简单多了， 往上升级即可。
有点天真的想法……