[心得] C與C++的辯論
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
C_and_CPP 近期熱門文章
PTT數位生活區 即時熱門文章
