※ 引述《tinlans ( )》之铭言： : 而软体系统的规模日益增大， : 8 万行内的小型软体系统用这种方法写还说得过去， : 70 万行以上的软体系统这样搞还是难逃一劫。 这就是目标差异了。我做的程式主要都是一万行以下的核心系统， 不用管杂七杂八的客户需求变动，除非需求变动超过核心系统所能 支援的范围。 一般都是客户开一个规格出来，我做出一个超出客户规格所需要的 通用模组、元件、服务或是虚拟机器、平台、解译器之类的东西， 其他就由别人处理。基本上我认为 programmer 做到这样的地步， 也差不多够了，追求超大型专案制作未必有意义，因为那样就会有 太多脑残需求要处理，实在是很浪费生命。 就这样的方法来看，我不认为世上那麽多百万行的系统，真的都是 需要那麽多行的程式码，真的需要那麽多复杂的设计。 至於过去超过十万行的程式，我还没试过不用 C++ 的，第一次接 大型专案就刚好遇上 Turbo C++ 1.0 问世，若是不考虑我现在的 软体开发方法，基本上我可以说大致同意你的观点。 : 上述做法存在着新的问题， : 就是 object 之间互相 assign 的机制必须手工制作， : bitwise copy 并非永远适当的方法， : 所以你绝对不可能单靠一个 memcpy 就搞定， : object 与 object 间的 copy 语义实现， : 仍是一个繁琐的任务。 这就牵涉到 object tree 的问题了，实际上 class, data, function 的 组合是不够的，至少还要加上 object, 在建立一个新物件之时，还要同时 建立其从属的子物件，一个 object 实质上会是四种 pointer 的组合。 所以最好是能建立一个完整的 object handler 机制才行。包括 class, object, data, function 都由这个 object handler 来处理。 特别是建立 object tree 结构，同时也解决 GC 问题，在一个物件消灭时， 所有从属物件也会跟着消灭。 这样子就不再需要手工制作 object 的 assignment, 大致上只有少数不是 子物件复制的特例需要处理，这在 C++ 当中也一样要特别做处理，而且有 许多额外的弹性机制存在。因为一个物件的从属物件是可以不固定的。 比较现实而言，用 C 而不用 C++, 要嘛是建立简单的结构，要嘛就是建立 超越 C++ 内建机制的复杂机制，只是这两种状况，在核心系统制作时，都 可能出现。 其实 C++ 在物件导向上，所实现的动态机制是相当有限的，一些原本使用 smalltalk 的朋友，在转向商业软体开发时，往往第一个选择，就是用 C 实作物件导向，而不是采用 C++. 在这个意义下，是很可以用 C 完成更加完整的物件导向机制的。只是往往 没有必要，我能做也想过，但始终没下手去做。 : 你每增加一个 subclass， : 就得重新实作一次新的 assignment operation。 : 还不只拿是 object_assign_class4(&object3, &object4);， : 来取代 object3 = object4; 这麽简单而已， : 万一你用 by value 把整个 object 当 function argument 丢， : 你还得手动 copy 一个暂时物件出来丢， : 不然你就得规定所有 programmer 在接 object parameters 时， : 要记得把它们先 copy 一份。 这用 object handler 还可以完成更复杂的事。 我们可以传 object id, 在取得 object content 时才决定是否复制物件。 这样也可以大幅度减少拿物件作参数时的复制负担，在需要时才复制物件。 : 的确，现在的 C programmer 为了在被强迫用 C 的环境生存下去， : 多奇怪的工具和方法都能搞得出来， : 说真的已经见怪不怪了。 这不算什麽强迫吧，本来 C 就是这样的一个东西，在 C++ 出现之前已经 是这个样子了，而 C++ 本身一开始也是以 C with classes 的面貌，并且 是以 preprocessor 的形式出现。 : 只不过， : debug mode 的 error message 该如何实作又是一门学问， : 否则也只是在考验 programmer 的记忆力罢了， : 而且将系统交接给别人时， : 别人不见得有办法理解这些 messages 的意思。 这的确都是学问呢。 : debugger 还有不少超乎想像的能力， : 像是用 watchpoint 去抓有问题的 pointer accessing， : 或是当程式因为某因素掉入 infinite loop 时， : debugger 可以直接拦截下来看程式的状态， : 能省下不少时间成本。 这些情况都应该事先避免的，例如很多人都会实作 pointer table, 传值时不直接使用 pointer, 而是 pointer id, 然後在取值时自动 检查，并在 debug mode 时则显示发生错误的位置，更严谨一点的， 还同时检查资料型别。 当然, pointer table 建置及资料型别编码又是一个学问。 : 新人 training 的时间成本不一样。 : 首先，因为 C++ 已经统整了 OO syntax 标准， : 你就算能把 myclass class2; 和 sub_class() 那段用 macro 合成一行好了， : 问题就是没个标准， : 现在 A 公司跟你来个 INIT_CLASS2() 的 macro， : 然後 B 公司跟你来个 CREATE_CLASS2() 的 macro， : 当然我相信你也知道差异不会这麽单纯而已， : 员工从 A 公司跳到 B 公司去， : 整个机制几乎需要整个重新 training， : 而不能假设他在学校学过 C 的 OO 写法就能马上 default 他懂。 现在会使用 C 的情况，主要都是跟系统相关或核心功能的部分了，大概不会有人 叫新人来做的... 而即使是用 C++, 这个情况也没有好到哪里去，号称会 C++ 的有几个真的会了? 只会用不会改 iostream, 几乎完全不会用 STL 的，只怕占了大半，而若要用个 boost 大概连人都徵不到，这还是个即将成为标准的程式库呢，还不是都要从头 训练。 以现在的资讯教育状况，找个在学校里改过 bbs code 的就算中上了，从学校教 出来的，理论或许没有全还给老师，但写个三百行程式练习就躲回家不来上班的 大有人在。真是不指望了。 程度够的人教什麽都快，不懂的就慢慢熬吧，标准问题的差别没有想像中大。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.222.173.26