作者tomex (tomex_ou)
看板C_and_CPP
标题[心得] C与C++的辩论
时间Thu Jan 5 06:49:49 2006
C语言是以function为基础的循序性编程语言，但它缺乏如C++般物件导向的封装特性，假
如并非局限在某硬体条件或效能考量，我们应该选用C++来撰写程式。
有些乡民反对使用C++，觉得C就已经够用且贴近电脑基本结构，不需再花费其他成本来架
构一个抽象介面。我承认这是Case By Case的思考逻辑，但不应该成为基本原则，因为
C++在本质上真的比C好!
其实C++在物件导向构面上也不够C#先进，有时候在不新增关键字上使用#define语言来模
拟，反而让程式显得更dirty。例如，我最近在使用NeroAPI来开发光碟烧录的功能，其
API要进行初始化，但其自订结构变数不仅乱放(不统一放在某header档)且大杂锅的宣告
方式，导致初次使用前要一行一行trace其用法，相当地不人性。
若我来封装NeroAPI，我会做好程式物件的分类及布署方式，宣告型别上统一放在某个
header档，并利用overloading的方式建立虚拟介面，把一般常用的变数先宣告好，使用
者只要这样写道:
#include "NeroApi.h"
void main()
{
NeroApi* nero = new NeroApi();
string* list = nero->Devices;
nero->File->Add(path);
nero->Folder->Add(dir);
nero->Burn();
}
透过C++的特性，我可以封装成上述这样简单的作法，而不需预先始初化一大堆不了解的
底层结构变数。试问，假如你使用C，你能这样贴心封装及转化吗？
我深深觉得，在编程路上只追求个人成就及利益最大化，终究会输给团队开发的，而C只
能撰写功能良好的单一function，却无法将彼此间的运作逻辑也一并写入程式物件中，自
然是输给C++的物件封装功能。甚至该说，持不同意见各走各的路也没关系，但一旦要提
供给别人使用，就该回归软体工程的原则，而不是坚持自己熟悉的工具及语言。
C/C++的#include语言早已令人诟病，因为标头档间的关系必须自己处理，问题是谁懂得
引入的顺序及数量呢? 而C#的NameSpace概念则是在建构物件时，就能清楚彼此间的关系
及阶层，自然在使用时就自动减少许多错误，这本来就该这样做，但许多旧语言为了相容
性却不愿新增这样的支援，注定最後要被淘汰。
我们身为新人，在没有条件下，就该选择延伸性高的语言，而不是还偏执C这样古老的语
言，甚至为它护盘。
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 140.119.20.171