- 论坛徽章:
- 0
|
我一直都喜欢类似轻松风格但又提纲挈领的书,
<Unix编程艺术>我这里收藏了两个版本,
刚开始读样章就觉这就是我的菜,一定要拥有.
里面写的东西是你我胸中有,下笔纸上无的东西.
有一种相见恨晚的感觉,不得不佩服原作者的表达能力.
我接触到的unix.有Solaris和FreeBSD, Linux主要就是Redhat.
石油行业中Sun小型机微型机很常见.
因为几年之前很多勘探资料处理软件只有Solaris版本,
而Sun+Solaris仅仅是为了使用这些软件而购买的平台.
目前,很多Sun的机器也都装上了RHEL.Readhat上的专业软件也越来愈多.
很多原本只能在Solaris上运行的软件纷纷移植到了Linux平台上,不由得感叹Sun的衰落.
最近一年来我们公司一直在参与一个项目,
要把公司的windows下的程序都迁移到linux环境下.
其中的艰辛不言而喻.当初写这个程序之时,正是九十年代,
那时国内电脑本来就少见,并且都是windows一统天下.
由于时代的局限性,当初写代码的时候完全没有考虑到可移植性.
就拿一个简单的例子来说,程序里充斥着MFC下最常用的CString.
为此,我们用标准C++实现了MFC的CString的一个兼容版本DString.
相当于加了一个中间层来实现可移植性.
如果现在重新写的新程序的话,肯定会把可移植性放在首位,
目前公司的规定就是首选用标准c/c++来实现,
其次考虑boost等准标准库.最后再考虑Qt等跨平台库.
我们重写后的程序和Linux的思想不谋而合:
用大量小程序通过脚本来连接,来完成一个大任务.
各个小程序之间是通过文件作为数据的管道来传输.
当数据文件从最后一个处理程序传递出来,任务也就完成了.
中间遇到的的最大麻烦,
是Windows与Linux之间一些很微妙的区别.
比如说Linux和Windows都有所谓的命令行脚本
(在linux下叫做Shell脚本,在Windows下是dat批处理)
其中有很多类似的命令,比如说cd,rm,等等,
正是这些微妙差别之处,浪费了我们大量的调试时间.
为了解决这个问题,我们写了一个脚本生成器,定义了一个新的脚本语言
然后在不同的平台下,生成对应平台的脚本.
为了能最大程度上保证程序在windows和Linux下的一致性,
所有的核心程序都是命令行界面(CUI)而非图形界面(GUI),以标准C/C++写成
在可执行文件内部标志一个字符串,然后用Qt写一个解析程序,
能自动解析可执行程序文件里面包含的标记字符串,生成对应的输入对话框.
这样核心功能由CUI程序完成,CUI程序又被GUI程序包装起来.方便用户的交互操作.
正应合每个程序只完成一个任务.把界面交互交给一个单独的任务来完成的思路.
之所以觉得此书相见恨晚,
这几天我正打算在去读博士之前的半年时间,把我之前写的程序重构一遍,
就我自己而言,心中那种构建高大全程序的冲动一直在心中翻覆.
现在下手重写的时候,我用到了模板库,多线程,智能指针,Boost库.各种新的技术无所不用其极.
看了此书,条条建议对我都是淳淳教诲.是我该重新审视的时候了.
或许对我来说,迅速搭建一个可运行的原型才是正途.或者说简单就是美好.
至于性能和先进性,此后再慢慢优化. |
|