仅就我能回应的部份回应，毕竟我也没什麽料。 ※ 引述《guest0079 (火辣辣的大姊姊)》之铭言： : 　一般认为C++效能较差是有几点现实上的考量： : 　a. C++太多太杂太难掌握，让程式人员浪费太多时间在语言本身而非问题的最佳解上 这和程式的效能无关。如果你要说的是 C++ 的某个语言特性使得实作某些演算 法变得很困难，请举出具体实例，而且你还要证明用 C 实作会比较简单。 : b. C++会偷偷增加一些程式码来维持本身的OO特性，一不小心就多出了不必要的code : c. C++会偷偷增加一些程式码来维持运算子过载特性，一不小心就多出了不必要的code 同上，请就这两点举出具体实例并证明同样的功能在 C 中并不会造成额外负担。 : 　d. 用C++物件导向实作的函式库，很方便使用没错，但代价就是负担太大(如Qt) 所以负担是什麽？同样的功能用 C 实作可以快多少？ : e. ...应该还有很多我不知道的 : 2.C++程式不易读 : 运算子过载真是太好用了，而且程式一看就懂，真是太好维护了，但是如果… : 　 Man a_man("大雄"); // 定义一个男人 : 　 Woman a_woman("静香"); // 定义一个女人 : int money = MAX_VALUE; : 　 printf("干这是什麽鬼：%s", a_man + money + a_woman); : 　这种code要怎麽维护？先回头找一下Man与Woman中operator + 的定义 : 　再确认与int作运算表示什麽，再查一下书看看运算的顺序的先後关系，如果operator : 　中又用到其他operator的过载，又要再去查，为了追一个问题，又引起n个问题，为 : 　了确认n个问题，又出现n^2个问题…没完没了。程式很简洁没错，但是要怎麽debug？ : 　难道每一行程式都要猜猜看吗？ 所以改用 C 的写法是像这样罗？ printf("干这是什麽鬼：%s", Add_Something_Woman( Add_Man_Int(a_man, money), a_woman) ); 也不是不行啦，只是有天你发现 int 不够用要改成 long 的时候，麻烦就很 大了。而且你一样也是要去看 Add_xxxx 这些 function 的内容才知道他们 做了什麽事，而且这些 function 也会用到其它 function，debug 起来并不 会比较简单。 另外你自己也说了，「运算子过载真是太好用了，而且程式一看就懂」。这意 味着如果你会写出自己看不懂的 code，那你就不该用 operator overloading。 你可能会说，这是某个「自以为很厉害的人」写出的 code，你不得不用，那 可能是以下的情况： 1. 大家都看不懂，只有「自以为很厉害的人」看得懂 code。 这种情况当然是「自以为很厉害的人」该死。 2. 一半的人看得懂，另外一半看不懂。请你们在下次技术团队会议时好好 讨论要不要改做法。 3. 大家都看得懂，你看不懂。很不幸的，这种情况下是你该多念点书。 : 好的物件导向远比C好维护，不过C++决对不是好的物件导向语言(这句话一言难尽) : 3.物件导向不适合底层程式 : 了解物件导向的人就知道，它是较贴进人类思维的程式写作方法，反之，它就不是 : 　一个贴近底层机器运作原理的编程原则，机器语言、组语才是最贴近底层运作机制的 : 　语言，想要用OO来描述机器的行为、自然法则、各式各样的protocol…等等诸如此类 : 　的运作机制容易流於天马行空，任意妄为。如果硬要用物件导向来实作底层机制，可 : 　能十个人有十二种不同的见解，没人看得懂彼此的程式，因为每个人对机制的感受都 : 　不一样，物件结构的分析各有各的看法，没完没了。 : 　当然，不用物件导向也是可以写C++程式，但那还不如用C来的单纯 : 　(但个人偏爱用完全无继承机制的物件架构来写C++，来当作是C的加强版) 就我的认知，物件导向的目的并不是要贴近人类的思维，而是为了软体易於维护 并扩充功能。所以如果对一个系统该如何设计，若是每个程式设计师都有自己的 意见，那当然是坐下来好好讨论哪一个做法比较容易维护、扩充。 当然，程式设计师意见不合是常有的事，但并不如你所想象的那样是天马行空的 争论，而是而实际地考虑各种设计在维护及扩充上的优劣。 : 4.C++的复杂度太高 : 　C公认的圣经只有一本，内文也才两佰多页，一本C++的入门书就一仟多页(C++ Primer) : C++的功能及其运作细节多如牛毛，写了10年的程式也许还会看到自已不懂的语法，或是 : debug时发现某个平常不会注意的细节在作怪，这如果只是开发一般的AP还好，如果是开 : 发OS这种大型、不易物件化的程式时，事情就大条了。因为： : a.开发人员太多，每人都用一种冷门的技巧，那要trace code就要买十本C++在身边才行 : b.总有人喜欢卖弄技巧，喜欢来个多重继承，自行定义运算子，把程式的复杂度弄得很高 : 　自以为很强，等到程式成长到自已无法控制(可能久了也忘了)才双手一摊说：比尔盖兹 : 　对不起，我要去Google上班了 : c.自已乖一点不要写出太复杂的程式就好了吗？不！因为C++支援太多种技巧、style， : 　所以有时候不得不乖乖配合别人的程式风格，想维持单一模组风格的一致性也很因难 : OS不是少数几个人就能写出来的程式，一定要有不少人力来大量的分工才能完成 : ，但高度的分工之後又必需维持紧密的偶合关系，是一项复杂度很高，极易失败的专案 : ，如果再用一个复杂度相对较高的C++工具来写的话，就难上加难了 团队开发本来就应该要先统一好 coding style，此外像是类别应该要有什麽行 为、提供哪些 method、哪些东西使用 template，则是在设计阶段就应该订好， 如果有某个程式设计师喜欢搞怪不合作，那换用 C 他还是可以完全不合作。 为了避免使用者滥用，程式语言不应该提供太多复杂的功能吗？那 C 应该先把 指标拿掉。 #define 也应该要拿掉，不然有人会写出下面这种东西： #define begin { #define end } : 最後，我很好奇某人说：C++的sort大胜C的qsort，理由何在？ qsort 每次对元素进行比较的时候，都要透过 function pointer 去呼叫 compare function。如果你学过 computer architecture 就会了解，使用 function pointer 会比一般的 function call 还慢，尤其 function 的 内容很短的时候，这个额外的负担就占了很大的比例。 因为 C++ 的 sort 是 function template，是在 compile time 就把静 态的 function call 插进 sort 里面，而且若 compare function 很短， 还可以得到 inline 的好处，进一步省掉 function call 的成本，当然 会比 C 的 qsort 快上不少。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.121.115.112 ※ 编辑: littleshan 来自: 59.121.115.112 (03/07 13:40) ※ 编辑: littleshan 来自: 59.121.115.112 (03/07 13:41)