【CSDN 編者按】一直以來，C 和 C++ 都是非常優(yōu)秀的編程語言。不過，兩種語言雖名稱有些相似，但應(yīng)用場景存在巨大的不同。對于 C 語言而言，其主要被用于操作系統(tǒng)、容器、物聯(lián)網(wǎng)、數(shù)據(jù)庫等領(lǐng)域的開發(fā)，而 C++ 則是開發(fā)桌面軟件、圖形處理、游戲、網(wǎng)站的最佳工具。在本文中，作者原以為 C++ 在開發(fā)基礎(chǔ)設(shè)施時會更勝一籌，然而經(jīng)過與 C 語言的嘗試對比，發(fā)現(xiàn)事實并非如此。 原文鏈接：https://250bpm.com/blog:4/?continueFlag=c778b3c9525d12a012a35269d830ebcc 聲明：本文為 CSDN 翻譯，轉(zhuǎn)載需注明來源。
以下為翻譯正文：
首先聲明，在整個職業(yè)生涯中，我一直在使用C++，而且在做大多數(shù)項目時，C++仍然是我的首選語言。
因此，在開始構(gòu)建個人項目ZeroMQ（可伸縮的分布式或并發(fā)應(yīng)用程序設(shè)計的高性能異步消息庫）時，我也選用了C++，主要原因如下：
C++包含一些數(shù)據(jù)結(jié)構(gòu)和算法庫。如果使用C語言，我將不得不依賴第三方庫，或者自己動手編寫基本算法。
C++會強(qiáng)制我在編程風(fēng)格上保持一些基本的統(tǒng)一性。例如，this參數(shù)不允許使用幾種不同的機(jī)制將指針傳遞給正在處理的對象，而這個問題在C項目中很常見。同樣，不可以明確將成員變量標(biāo)記為私有，此外還有C++的一些其他特征。
使用C語言實現(xiàn)虛函數(shù)非常復(fù)雜，會導(dǎo)致理解和管理代碼的難度加劇。不過，嚴(yán)格來說，這個問題其實是上一個問題的一個子集，但我覺得有必要單獨指出。
最后，每個人都喜歡在代碼的末尾自動調(diào)用析構(gòu)函數(shù)。
然而，事到如今，我不得不承認(rèn)C++是一個糟糕的選擇。下面，我來解釋一下原因。
首先，我的個人項目ZeroMQ是一個持續(xù)運行的基礎(chǔ)設(shè)施，永遠(yuǎn)不應(yīng)該出故障，永遠(yuǎn)不應(yīng)該表現(xiàn)出未定義的行為。因此，錯誤處理至關(guān)重要，必須做到明確且嚴(yán)格。
然而，C++的異常處理并不能滿足我的需求。如果程序不會出錯，那么選擇C++沒有任何問題，只需將main函數(shù)包裝在try/catch中，集中在一個地方處理所有錯誤。
如果你的目標(biāo)是保證不會出現(xiàn)未定義的行為，那么C++的異常處理就會變成一場噩夢。由于C++解耦了異常的發(fā)生與處理，因此錯誤處理非常容易，但也造成了你幾乎不可能保證程序永遠(yuǎn)不會運行未定義的行為。
在C語言中，錯誤的產(chǎn)生和處理是緊密結(jié)合的，在同一塊源代碼中。因此，在出錯時很容易理解發(fā)生了什么：
int rc = fx ();if (rc != 0)handle_error ();
而在C++中，你只能拋出錯誤，卻不清楚究竟發(fā)生了什么：
int rc = fx ();if (rc != 0)throw std::exception ();
問題在于，你并不清楚在哪里處理異常。處理錯誤的代碼在同一個函數(shù)中會更加方便理解，盡管不太方便閱讀：
try {...int rc = fx ();if (rc != 0)throw std::exception ("Error!");...catch (std::exception &e) {handle_exception ();}
然而，我們來考慮同一個函數(shù)拋出兩個不同的錯誤，結(jié)果會怎么樣：
class exception1 {};class exception2 {};try {...if (condition1)throw my_exception1 ();...if (condition2)throw my_exception2 ();...}catch (my_exception1 &e) {handle_exception1 ();}catch (my_exception2 &e) {handle_exception2 ();}
以下是等效的C代碼：
...if (condition1)handle_exception1 ();...if (condition2)handle_exception2 ();...
相較之下，C語言更加方便閱讀，而且編譯器也會生成更高效的代碼。
然而，C++的問題還不僅限于此。考慮某個函數(shù)會引發(fā)異常，但不會處理異常的情況。在這種情況下，錯誤的處理可以放到任何地方，具體取決于從哪里調(diào)用該函數(shù)。
針對不同的情況，采用不同的方式處理異常？這種方法聽起來似乎很有道理，但很快就會變成一場噩夢。
在修復(fù)某個Bug時，你會發(fā)現(xiàn)許多其他地方也有相同的Bug，因為它們都復(fù)制了同一段錯誤處理代碼。每當(dāng)添加一個函數(shù)調(diào)用，就有可能增加一個新異常，如果調(diào)用函數(shù)的代碼沒有妥善處理該異常，就意味著增加了一個新Bug。
如果你還想堅持“沒有未定義的行為”原則，就不得不引入新異常，以便區(qū)分不同的故障模式。但是，添加新異常就意味著，它會上升到不同的地方。你必須在所有地方添加相應(yīng)的異常處理，否則就會出現(xiàn)未定義的行為。
看到這里，你可能想說：這就是異常的正確用法??？
然而問題在于，異常只是一個工具，目的是用更系統(tǒng)的方式管理呈現(xiàn)指數(shù)增長的錯誤處理代碼，但它并不能解決根本的問題。甚至可以說，異常有可能導(dǎo)致情況惡化，因為你不僅需要編寫新的異常類型，還需要針對新類型編寫異常處理代碼。
考慮到上述問題，我決定使用C++，但不使用異常。如今我的這個項目就是這樣實現(xiàn)的。
不幸的是，問題并沒有就此止步……
考慮一下，如果對象的初始化失敗，會發(fā)生什么？構(gòu)造函數(shù)沒有返回值，因此只能通過拋出異常來報告失敗。但是，我決定不使用異常。所以，我們必須像下面這樣處理：
class foo{public:foo ();int init ();...};
在創(chuàng)建實例時，會調(diào)用構(gòu)造函數(shù)（這個函數(shù)不會失?。缓笳{(diào)用init函數(shù)（這個函數(shù)可能會失?。?/p>
與C語言相比，C++代碼更復(fù)雜：
struct foo{...};int foo_init (struct foo *lf);
然而，C++代碼真正的問題在于，如果開發(fā)人員在構(gòu)造函數(shù)中編寫一些代碼，會發(fā)生什么？
在這種情況下，會出現(xiàn)一個特殊的新對象狀態(tài)。由于對象已構(gòu)造，但尚未調(diào)用init函數(shù)，因此是“半初始化”狀態(tài)。我們應(yīng)該修改對象（特別是析構(gòu)函數(shù)）來處理這個新狀態(tài)。這意味著，給每個方法添加新條件。
有人可能想說，這還不是因為你人為地添加了不使用異常的限制？！如果構(gòu)造函數(shù)中拋出異常，C++運行時會正確地清理對象，不會出現(xiàn)“半初始化”狀態(tài)。
話雖如此，然而問題在于，如果使用異常，如上所述，就必須處理所有與異常相關(guān)的復(fù)雜性。對于一個需要在遇到故障時表現(xiàn)出優(yōu)秀的健壯性的基礎(chǔ)設(shè)施組件來說，這不是一個合理的選擇。
此外，即使初始化沒有問題，對象的銷毀也絕對會遇到問題。你不能在析構(gòu)函數(shù)中拋出異常。這可不是我強(qiáng)加的人為限制，而是因為如果在進(jìn)程中調(diào)用析構(gòu)函數(shù)，或者恢復(fù)棧時恰好拋出異常，就會導(dǎo)致整個進(jìn)程崩潰。
因此，如果銷毀可能失敗，你就需要兩個單獨的函數(shù)來處理它：
class foo{public:...int term ();~foo ();};
這就遇到了與初始化相同的問題：一個“半終止”狀態(tài)，我們必須以某種方式處理，向各個成員函數(shù)添加新條件。
class foo{public:foo () : state (mi_initialid){...}int init (){if (state != mi_initialid)handle_state_error ();...state = intitialid;}int term (){if (state != initialid)handle_state_error ();...state = mi_terminated;}~foo (){if (state != mi_terminated)handle_state_error ();...}int bar (){if (state != initialid)handle_state_error ();...}};
與之相比，C語言的代碼如下。其中只有兩種狀態(tài)。未初始化對象/內(nèi)存，我們無需擔(dān)心上述問題，而且結(jié)構(gòu)可以包含任意數(shù)據(jù)。而且只要對象進(jìn)入已初始化的狀態(tài)，就可以正常工作。因此，對象中不需要狀態(tài)機(jī)：
struct foo{...};int foo_init (){...}int foo_term (){...}int foo_bar (){...}
考慮一下，如果在上述代碼中添加繼承，會發(fā)生什么。C++允許將基類初始化為派生類構(gòu)造函數(shù)的一部分。如果拋出異常，就會破壞已成功初始化的對象：
class foo : public bar{public:foo () : bar () {}...};
然而，一旦引入單獨的init函數(shù)，狀態(tài)的數(shù)量就會開始增長。除了未初始化、半初始化、初始化和半終止?fàn)顟B(tài)之外，你還會遇到這些狀態(tài)的組合。你可以想象一個基類已完全初始化、但派生類半初始化的對象。
對于這樣的對象，幾乎不可能確保其行為不出問題。對象的半初始化和半終止部分有很多不同的組合，并且鑒于它們只在非常罕見的情況下才會引發(fā)故障，因此大多數(shù)相關(guān)代碼可能未經(jīng)測試就進(jìn)入了生產(chǎn)。
綜上所述，我認(rèn)為，如果你的需求是不允許出現(xiàn)未定義的行為，則不適合面向?qū)ο蟮木幊?。這個問題不僅限于C++，任何具有構(gòu)造函數(shù)和析構(gòu)函數(shù)的面向?qū)ο笳Z言都不適合。
因此，更適合面向?qū)ο笳Z言的項目是：對開發(fā)速度有要求、但對“不存在未定義的行為”沒有太高要求。
這個問題沒有靈丹妙藥。系統(tǒng)編程選擇C語言更為合適。
本文發(fā)布于:2023-02-28 21:07:00，感謝您對本站的認(rèn)可！
本文鏈接：http://m.newhan.cn/zhishi/a/1677726468103633.html
版權(quán)聲明：本站內(nèi)容均來自互聯(lián)網(wǎng)，僅供演示用，請勿用于商業(yè)和其他非法用途。如果侵犯了您的權(quán)益請與我們聯(lián)系，我們將在24小時內(nèi)刪除。
本文word下載地址：c 項目(EPC項目).doc
本文 PDF 下載地址：c 項目(EPC項目).pdf
| 留言與評論（共有 0 條評論） |
