开发工具的选择: c or c++? c# or java or Python?-CSDN博客

前不久手头有两个软件需要同步开发，且成为软件A 和软件B 吧，面临开发工具的选择：

软件A ：有两个版本， PC edition和mobile edition. 分别运行在普通的PC环境和手持设备上。
核心部分基于同一棵源代码树。平台相关部分单独编写和优化。这个软件要完成的功能是实时
的显示和诊断低速(<11000bps)和中速(<500kbps)工业控制网络。工业控制网络和PC间的信号转换
已经有现成的设备支持， PC只需处理经USB口或者bluetooth接收上来的数据，并向网络发送控制
命令就可以了。mobile edition的通信模块有成熟的电路可用，这里不用考虑。

软件的核心部分之一是一个类似行为树的结构，可以基于Finite State Machine或者PetriNET，
另一个主要的部分是通信，需要支持包括CAN在内的协议。

对这个软件来说语言上的选择非常有限，基本上是在两条路中选一：全部用C开发；或者
用C/C++混合开发。我心里非常倾向于用纯C开发全部产品代码，这样做的好处显而易见：
既可以跑在PC平台上，又可以方便为未来的mobile edition选择性价比高的硬件平台。
比如我熟悉的两种日系平台(toshiba T900, Renesas M16)价格非常有吸引力,只有C语言
开发套件。但是用C语言开发也有很大的缺点：凭我个人绝对不可能在有吸引力的时间完成这个
软件的第一个版本，而且我身边找不到出色的写较大规模C程序的能手。

C++有不少优点，它的库比C丰富，可以直接使用STL里面的结构快速的写出原型，
我曾用下班前的两个小时用STL基本实现了PETRI-NET的功能，而花了一个星期还没有完全调通一个
用C写的运行时行为可变的FSM。C++对我来说最大的问题是阻止了我硬件成本的下降，想想看
C++程序很难跑在一个用16位MCU加512K RAM/2M ROM搭建起来的平台上(还不考虑编译器支持问题)，
即使只和一个很小的内核和文件系统捆绑在一起。

图形界面是非常复杂的一部分，因为要跨平台还要考虑性能。QT是一个不错的选择，但是
QT对嵌入式环境要求不低，费用也是不得不计较的。这个部分我准备使用公司目前在用的图形库，
价格公道，性能还可以，因为以前我做过类似的移植工作，所以是完全可行，缺点是图形界面
不够丰富，没法和QT相比。按照目前流行的做法，常规的图形界面抽象出来做成数据驱动的界面，
数据格式已经定好了，但是访问数据的代码还没有动手。

软件B ：软件B实际上作为软件A的二次开发环境被单独开发，运行在windowsXP上。功能如下：
一个类似labview的图形编辑环境，以可视化方式编辑有限状态机和Petri-NET；数据库访问部分，
数据库使用SQL SERVER 2005；数据生成部分，最终生成定制的二进制格式文件。软件A的图形界面
编辑和生成部分，这个部分输出的数据用来驱动A的界面变化。

前段时间我试着在Netbeans 6环境下用java/swing为软件B写了一些代码，但是最终失败了。原因有以下几点：
1) 我以前从来没有用java写过哪怕一个有用的程序;
2) 我不熟悉Swing;
3) Netbeans我用不习惯（但不可否认这个IDE给我留下了非常深刻的印象）

后来我打算回头用C++来开发软件B。在windows下，如果开发大一些的软件，有如下几个选择：
1) VC++/MFC: 我用曾经用这套工具写过几个规模不大的程序，但并没有涉及非常复杂的图形界面，不过我曾经参加
一个庞大的用win32/C开发的产品并提交过数量不少的产品代码，所以MFC图形界面开发对我来说学习曲线并不陡；

2) C/Win32 API，虽然很熟悉这种开发方式，但目前身边的人并不屑这样做，遂放弃。

3) VC++/CLR: 我曾就这个问题问过以前在Microsoft工作过的同事，他并不推荐和CLR搞在一起的C++，
但他向我推荐C#，可见CLR还是能成事的。

4) Python/wxWidgets: 用python写过一些小工具，但以我所知道的用这套组合工具开发的软件，有名一点的好像
只有Chandler，一个不太成功的开源项目。而且我不熟悉wxWidgets.

5) C#: 来自MS的同事强力推荐这个。我在07年用C#写过一个基于PC的控制单元模拟器，USB口收发数据，数千行代码，仅此而已。印象深刻的就是最新的Visual Stdio 2005贴心的开发环境(以前用的VS版本仅限于6)。C#的语法和巨大的.net库是参照MSDN现用现学的。看来C#还真是开发软件B的强有力的候选者。

6)Java/Swing: java本来不在我的考虑之内。在职业生涯的前面几年里我赖以生存的基本就是C和C++，第一次领略到
java的能力是一个同事给我演示他的一个不大的程序，寥寥百十行代码，访问数据库，生成定制格式的数据。
估计换成我用C要折腾半天还不一定搞的定。当然我也知道J2EE以及众多开源框架的大名，但跟我的工作并不相干，
所以没有理会。现在看来要重新评估java在PC桌面开发的能力了，遂让公司给买了core java2影印版两卷开始翻，觉得
java可以满足这样一个中等规模的，侧重在用户交互和图形界面的，访问数据库的软件。身边的C/C++程序员也大多
愿意学习这样一门新的语言(对我们来说)。

结论：最后的选择结果是，软件A我们使用了C++，因为我们都非常熟悉C++，大多数同事有5年以上的C++软件
开发经验, 用纯C比较冒险，重新实现很多数据结构不说，完整的测试这些基础设施也非常耗时。当然我们用C++付出
的代价是软件A mobile edition的运行环境不低于这个水准： 140 MHZ 以上的RISC机器， 32M SDRAM以及3.5'TFT LCD，以及winCE系统。目前进度还算乐观：最核心的几个功能已经写好了。正在为PC版本写平台相关代码。

软件B选择用C#是反复权衡的结果，MS的桌面开发成熟程度还是比较高，我们还是倾向于保守的选择。J2SE可能确实有不少我不知道的重量级应用实例，但是我个人感觉它的开发环境比Microsoft的差一些。我想也许J2SE有统治桌面开发的那一天。但是现在我必须得把东西做出来，一个粗糙的版本也好，否则老大见不到DEMO，我们也就申请不到资源，后继的开发根本无从谈起。软件B 最困难的图形符号编辑部分还没有动手，由图形生成的数据描述文件的格式已经定好，解析这些文件的代码也已经调试通过，可以使用了。