是的，C ++在嵌入式系統中仍然有用。就像其他人所說的那樣，它仍然取決於系統本身，就像8位uC在我的書中可能是不行的，即使那裡有編譯器並且有人這樣做（顫抖）。即使在8位微型環境中，即使將C ++縮小到“ C +”之類，使用C ++仍然有一個優勢。我所說的“ C +”是什麼意思？我的意思是不要使用new / delete，避免異常，避免具有繼承的虛擬類，可能一起避免繼承，對模板要非常小心，使用內聯函數而不是宏以及使用 const 變量

我已經在嵌入式系統中使用C和C ++進行了十多年的工作，而我對C ++的年輕熱情肯定已經消失了由於一些現實世界中的問題而動搖了天真。我已經看到了嵌入式系統中最糟糕的C ++，我將其稱為“ CS程序員在EE世界中瘋狂”。實際上，這就是我正在與我的客戶合作以改善他們擁有的這一代碼庫的東西。

C ++的危險在於，它是一個非常強大的工具，就像一把兩刃劍，如果不正確地接受其語言和通用編程本身的教育和訓練，就會割傷您的胳膊和腿。 C更像是單刃劍，但仍然一樣鋒利。使用C ++，很容易獲得非常高級的抽象並創建混淆的接口，這些接口從長遠來看變得毫無意義，這部分是由於C ++能夠靈活地用多種不同的語言功能（模板，OOP，程序， RTTI，OOP +模板，重載，內聯）。

我完成了由C ++專家Scott Meyers進行的兩個4小時的有關C ++嵌入式軟件的研討會。他指出了有關模板的一些我從未考慮過的事情，以及它們可以幫助創建安全關鍵代碼的更多信息。關鍵是，您不能在必須滿足嚴格的安全關鍵代碼要求的軟件中包含無效代碼。模板可以幫助您完成此任務，因為編譯器僅在實例化模板時創建所需的代碼。但是，必須對它們的使用進行更徹底的教育才能正確地設計此功能，這在C語言中很難完成，因為鏈接器並不總是優化死代碼。他還演示了模板的功能，該模板只能用C ++來完成，如果NASA實施類似的系統來保護計算中的計量單位，那麼火星氣候觀察者將不會崩潰。

斯科特·邁耶斯（Scott Meyers）是關於模板和內聯的明智使用的非常大的支持者，我必須說，我仍然對模板感興趣。我傾向於迴避它們，即使他說只應將它們應用到成為最佳工具的地方。他還指出，C ++為您提供了製作非常好的接口的工具，這些接口易於正確使用，而難以錯誤使用。同樣，這是困難的部分。在您知道如何以最有效的方式應用這些功能成為最佳設計解決方案之前，必須先熟練掌握C ++。

OOP也是如此。在嵌入式世界中，您必須熟悉編譯器將要發布的哪種代碼，才能知道您是否可以處理運行時多態性的運行時成本。您還需要願意進行測量，以證明您的設計將滿足您的最後期限要求。新的InterruptManager類會使我的中斷等待時間過長嗎？還有其他形式的多態可以更好地解決您的問題，例如C可以做到的鏈接時多態，但是C ++可以通過 Pimpl設計模式（不透明指針）來實現。

我要說的就是C ++在嵌入式世界中佔有一席之地。您可以恨自己想要的一切，但它不會消失。可以用非常有效的方式編寫它，但是要比使用C來學習正確的方法要困難得多。在解決問題和表達更好的接口方面，有時它可以比C更好地工作，但是同樣，您必須教育自己，不要害怕學習方法。

C ++絕對適用於嵌入式系統。現在，我將是否存在良好的開發工具（或缺乏）作為我是否使用特定微處理器的主要標準。

在嵌入式系統上很好使用的C ++區域具有較低的資源成本：

• 通過良好使用類/結構帶來的模塊化
• 模板如果，編譯器在有效地編譯它們方面做得很好。模板是將算法重用引入不同數據類型的好工具。

確定區域：

• 虛擬函數–我以前反對這樣做，但是資源成本非常小（每個類一個vtable，而不是每個對象；每個對像一個指向vtable的指針；每個虛函數調用一個解引用操作），並且它的最大優點是它允許您要擁有一個包含幾種不同類型對象的數組，而不必知道它們是什麼類型。我最近使用了這個對像數組，每個對象代表一個I2C設備，每個對像都有單獨的方法。

不使用的區域，主要是因為運行時開銷在小型計算機上是不可接受的系統：

• 動態內存分配-其他人已經提到了這一點，但不使用動態內存分配的另一個重要原因是它表示時序不確定性；使用嵌入式系統的許多原因都是出於實時應用。
• RTTI（運行時類型信息）-內存開銷很大
• 例外-肯定是 否，因為執行速度不佳

是的，C ++當然適用於嵌入式系統。首先，讓我們澄清一些關於C和C ++之間區別的誤解：

在嵌入式微型計算機中，如果您擔心時間或空間，則總是需要謹慎使用高級語言。約束。例如，許多MCU不能很好地處理指針，因此在使用堆棧時效率很低。這意味著您在使用數組，指針和遞歸將變量傳遞給函數時必須格外小心。一個簡單的C語言行，例如：

  a [i] = b [j] * c [k];  

可以生成大約4頁的指令取決於這些變量的性質。

每當您使用任何高級語言，並且擔心時間和空間限制時，都需要了解每個的功能該語言的語言翻譯成MCU上的機器指令（至少，您使用的每個功能）。對於C，C ++，Ada，無論如何都是如此。可能所有語言都將包含在小型MCU上無法有效翻譯的功能。始終檢查反彙編清單，以確保編譯器不會生成大量瑣碎的指令。

C是否適合嵌入式MCU？是的，只要您注意生成的代碼即可。
C ++是否適合嵌入式MCU？是的，只要您注意生成的代碼。

這就是為什麼我認為即使在8位MCU上，C ++也比C更好：C ++為以下方面提供了更好的支持：

• 數據隱藏
• 更強的鍵入/檢查功能
• 使用類進行多周界透明化
• 模板（一如既往，請謹慎使用）
• 初始化列表
• const

這些功能都不比C的典型功能重。

當您最多移動16或32位MCU時，在功能更強大的MCU上以相同的方式使用更重的C功能（堆棧，堆，指針，數組，printf等）就變得有意義了。使用C ++的重功能（堆棧，堆，引用，STL，新建/刪除）變得合適了。

因此，無需在PIC16上對C ++的想法感到震驚。如果您正確地了解您的語言和MCU，那麼您將知道如何一起有效地使用它們。

我總是覺得閱讀這些辯論很有趣。關於各種可用語言的利弊的學術討論不是很多，而是因為您通常可以根據某人的工作/經驗/感興趣的領域來確定某人對該主題的立場。就在那兒，帶有“過早的優化”參數，這是CS專業人士和維護程序員在左右引用Knuth以及那些在現實世界中工作的人，他們認為性能非常瘋狂（我是後者的成員）公平地說。）

最終，您可以在這裡用C或C ++或插入語言開發出色的軟件。這取決於開發人員的能力，而不是語言。通常，只有當您選擇了錯誤的語言並且現在需要將其轉換為解決問題的方式時，才需要成為語言專家，在大多數情況下，這是唯一需要深入了解晦澀功能或編譯器的情況

我經常聽到人們以“我是X語言專家，等等”的理由開始爭論，因為我認為他們已經從錯誤的角度解決了問題，此後的一切都因他們渴望使用工具來解決問題並顯示問題的“酷”程度而受到困擾。

我經常看到開發人員首先選擇工具集並嘗試將其屈服於他們的問題，這是完全錯誤的，並導致了解決方案。

正如我在對另一個答案的評論中提到的那樣，這些語言之爭常常演變成爭論：語言X允許程序員做更多愚蠢的事情。在娛樂閱讀的同時，所有這些陳述實際上意味著您在僱用優秀的開發人員時遇到了問題，需要直接解決該問題，而不是通過繼續僱用不良的開發人員並選擇能夠使他們做得很少的工具來試圖解決問題。盡可能的損壞。

在我看來，好的開發人員，無論是軟件開發還是硬件開發，都要研究問題，設計解決方案並找到使他們能夠以“最佳方式”表達解決方案的工具。在使用3-4種語言/開發工具進行項目選擇新工具之後，是否需要使用的工具是您從未使用過的工具都沒關係，

當然，“最佳方法”是一個主觀術語，還需要在研究階段進行定義。一個人需要根據眼前的問題考慮許多問題：性能，表達的難易程度，代碼密度等。我之所以沒有將可維護性列入該列表是有原因的，我不在乎您選擇哪種語言，如果您選擇了合適的工具並花時間來理解應該免費的問題。難以維護代碼通常是由於選擇了錯誤的工具或較差的系統結構而導致的，這導致醜陋的雜亂無章，使其無法正常工作。沒有定義一個特定的感興趣的問題。面向對象的方法並不總是比功能方法更好。有一些問題非常適合面向對象的設計範例。有很多沒有。關於人們似乎喜歡使用的許多語言功能，可以做出相同的陳述。

如果您花費超過20％的時間在實際鍵入代碼的問題上，則可能是系統性能很差，或者開發人員性能很差（或者您還在學習）。您應該將大部分時間花在解決問題並確定應用程序各部分之間的交互方式上。將一群才華橫溢的開發人員放在一個帶有標記板和問題的房間中，並告訴他們在他們對整個系統感到滿意之前，他們不能編寫任何代碼或選擇任何工具，這將大大提高他們的質量。輸出和加快開發速度，而不是選擇任何熱門的新工具都可以保證縮短開發時間。 （將Scrum開發視為與我的論點相反的參考）

通常不幸的現實是，許多企業只能通過所寫的行數或通過查看“有形的輸出”。他們將在帶有標記板的房間中呆了3週視為生產力的損失。開發人員經常被迫加速開發的“思考”階段，或者被迫使用公司內部某個政治問題所設定的工具，“我老闆的兄弟為IBM工作，所以我們只能使用他們的工具”，這種垃圾。或更糟糕的是，您會從公司那裡收到一組不斷變化的需求，因為他們沒有能力進行適當的市場研究或不了解更改對開發週期的影響。對於這個話題，我對此話題有很強烈的看法。

以我的經驗，C ++通常不適用於小型嵌入式系統。我的意思是微控制器和無操作系統設備。

許多C ++ OOP技術都依賴於動態內存分配。在小型系統中經常會缺少這種功能。

STL和Boost確實展示了C ++的強大功能，兩者的佔用空間都很大。

C ++鼓勵程序員將計算機抽像出來，

去年，我將商業遠程桌面產品移植到了手機上。它是用C ++編寫的，並且可以在Windows，Linux和OSX上運行。但是，它嚴重依賴STL，動態內存和C ++異常。要使其在WinCE，Symbian和無操作系統環境中運行，最明智的選擇是C重寫。

任何語言都適用於嵌入式系統。嵌入式只是意味著：與免費使用的計算機相反，它是大型設備的一部分。

當要求進行（硬）實時 em 時，該問題具有更大的相關性。 >或有限資源系統。

對於實時系統，C ++是在對嚴格的時間限制進行編程時仍然適用的最高語言之一。除了堆使用（自由運算符）外，它沒有不確定的執行時間的構造，因此您可以測試程序是否滿足其計時要求，並且有更多的經驗甚至可以預測它。當然，應該避免使用堆，儘管新的運算符仍然可以用於一次性分配。 C ++通過C提供的結構可以在嵌入式系統中很好地使用：OO，異常，模板。

對於資源非常有限的系統（8位芯片，RAM不到幾Kb） ，沒有必需的堆棧）完整的C ++可能不適合，儘管它仍可以用作“更好的C”。

我認為很不幸，Ada似乎僅在某些壁ni中使用。從很多方面來說，它都是Pascal ++，但是沒有與一開始就已經很混亂的語言向上兼容的負擔。 （編輯：嚴重的混亂當然是C。Pascal是一門美麗但有些不切實際的語言。）

======================= ========================================

編輯：我正在鍵入一個新問題的答案（“在什麼情況下，當我們對微控制器進行編程時，C ++是必需的嗎？”），因此我將添加我寫的內容：

使用任何編程語言從來沒有一個完全否定的理由，但是在特定情況下某些參數可能具有或多或少的重要性。關於此問題的討論可以在很多地方找到，其職位範圍從“從不使用C ++用作微控制器”到“始終使用C ++”。我更喜歡最後一個職位。我可以提供一些論據，但是您必須自己決定它們在特定情況下（以及在哪個方向）所承擔的重量。

• C ++編譯器比C編譯器稀有。對於某些目標（例如12位和14位核心PIC），根本沒有C ++編譯器。
• （好的）C ++程序員比（好的）C程序員稀少，尤其是在那些（
• C ++比C具有更多的構造，不適用於小型系統（例如，異常，RTTI，頻繁使用堆）。
• C ++具有比C更豐富的（標準）庫集，但是先前觀點的結果是C ++庫經常使用不適用於小型系統的功能，因此在小型系統上不可行。 / li>
• C ++具有比C更多的結構，可讓您用腳射擊。
• C ++具有比C更多的結構，可讓您防止射擊
• C ++具有一組更豐富的抽像機制，因此它提供了更好的編程方式，尤其是對於庫而言。
• C ++語言功能（例如，構造函數/析構函數，轉換函數）使查看代碼以查看生成的機器變得更加困難，從而增加了語言構造的時空成本。
• C ++語言構造使您不必了解將代碼準確地轉換為機器代碼的方式，因為它們在“摘要”中做了“正確的事情”採取行動。
• C ++語言標準發展迅速，並且被大型編譯器（gcc，clang，microsoft）迅速採用。 C的發展相當緩慢，對某些較新功能（可變數組）的採用感到恐懼，甚至在以後的標準中也有所恢復。特別是這一點很有趣，因為不同的人使用它來支持相反的立場。
• C ++無疑是比C更為敏銳的工具。您是否相信您的程序員（或您自己）使用這種工具來實現這一目標一個美麗的雕塑，還是您擔心它們會傷害自己，您是否寧願選擇一款不太美觀但風險較低的產品呢？ （我記得我的雕塑老師曾經告訴我，鈍器在某些情況下比銳利的工具更危險。）

我的博客有關在小型系統（=微控制器）上使用C ++的一些著作。

我希望在有關裸機和資源受限系統上的C ++的討論中增加更多的熱量。

C ++中的問題：

• 異常尤其是一個RAM問題，因為所需的“緊急緩衝區”（例如，內存不足異常就在其中）可能大於可用的RAM，並且肯定對微控制器造成浪費。有關更多信息，請參見 n4049和 n4234。它們應該被關閉（這是當前未指定的行為，因此請確保不要拋出）。 SG14目前正在研究更好的方法。

• RTTI可能永遠都不值得開銷，應該將其關閉

• 大型調試版本，儘管在經典台式機開發中這不是問題，但如果調試不適合芯片，則可能是一個問題。問題來自於為清晰起見而添加的模板代碼或額外的函數調用。優化器將再次刪除這些多餘的函數調用，並且增加的清晰度或靈活性可能是一個很大的優勢，但是在調試版本中，這可能是個問題。

• 堆分配。儘管STL允許使用自定義分配器，但對於大多數程序員而言，這可能很複雜。堆分配是不確定的（即不是實時的），儘管進行了測試，但碎片會導致意外的內存不足情況發生。為了跟踪自由空間和變化的大小，堆所需的簿記可能是小對象的問題。通常最好使用池分配（在C和C ++中都是這樣），但這對於習慣只使用堆的C ++程序員來說可能是異常的。

• 運行時多態性和其他間接調用通常會嚴重影響性能，問題通常出在更多地方，因為優化器無法看到它們，而不是實際獲取和跳轉到地址。因此，在C和C ++中應避免進行間接調用，因為在C和C ++中，它們在文化中更加根深蒂固（並且在其他領域中非常有用）。

• 與clib的隱式接口可能會出現問題。 clib問題在C ++類別中可能是違反直覺的，但問題是由並發環境中的資源隱式共享引起的（在C中共享更明確）。通用newLib實現的使用通常會導致很多膨脹，這在uC中通常是不需要的，另一方面，newLibNanno不是可重入的，因此必須序列化對其進行訪問（在此過度簡化）。對於C來說也是一個問題，但是訪問更為明確。根據經驗，除非您確定它不會以某種方式訪問clib中的狀態（例如，errorno或堆），否則基本上不應在ISR上下文中使用命名空間std中的任何內容。如果您正在使用線程（我更喜歡RTC）來覆蓋new和delete以同步對malloc和free的訪問，這也很重要。

總而言之，C ++存在一些問題，但它們基本上都是可修復的或可避免的。

現在對於C，這裡的問題是高階。我沒有C語言的語法能力來抽象事物，而我無法在編譯時執行優化或檢查不變式。因此，我無法以某種方式正確地封裝事物，即用戶不需要知道它們的工作方式就可以使用它們，而我的大部分錯誤檢測都是在運行時完成的（這不僅為時已晚，而且會增加成本）。 本質上，在C語言中通用的唯一方法是通過數據，我將格式字符串傳遞給printf或scanf，例如在運行時對其進行評估。然後，對於編譯器來說，很難證明我沒有使用某些選項，這些選項在傳遞正確的數據時理論上是可行的，這意味著潛在的死代碼生成和優化潛力的損失。

我知道我可能會在這裡引發一場風暴，但是我在32位微控制器上的經驗是，在專家之間編寫的C和C ++的比較中，C ++是效率更高的語言。只要一切都需要完全通用（就像在任何庫中一樣），並且在非通用情況下它們基本上是等效的。對於新手來說，利用C ++中的專家庫實現者的專業知識也更加容易。

同時，實際上實際上只有很少的函數不能傳遞不正確的數據，只要輸入不是int而是 something ，而我恰巧使用了int作為一種表示方法，則可能會出錯（​​傳遞無效值或“ otherThing”而不是“ something”）。在C語言中，檢查用戶是否輸入錯誤的唯一方法是在運行時。在C ++中，我可以執行一些檢查，而不是全部檢查，但可以在編譯時執行一些免費的檢查。

在一天結束時，C團隊通常與其最弱的程序員一樣強大，並且所得到的代碼收益是多人遊戲1或性能損失。我的意思是，在一個獨特的設計決策獨特的環境中，它要么是一項工作的高性能，要么是一項獨特的工作，或者它足以在多種環境中使用（其他微控制器，其他內存管理策略，其他延遲vs.）。吞吐量的取捨等），但具有固有的性能成本。

在C ++中，事情可以由專家進行封裝，並在許多環境中使用，在這些環境中，編譯時代碼生成可適應特定任務，而靜態檢查可防止用戶以零成本進行愚蠢的工作。在這裡，我們在通用和快速之間的權衡要少得多，因此最終從成本與收益的角度來看，是一種性能更高，更安全和更俱生產力的語言。

一個很好的批評是，仍然缺少用於嵌入式的良好C ++庫，這可能導致務實的決定，即在C ++編譯器上主要使用C。在項目中僅使用C的決定本質上是出於意識形態的驅動，出於對遺留支持的需求，或者承認團隊的紀律性不足以避免選擇C ++而不是C可以完成的一系列愚蠢的選擇。同時要有足夠的紀律性，以至於不能做任何愚蠢的事情，而這在C語言中是無法防範的，而在C ++中是可以避免的。

我的背景：剛從貝爾實驗室老程序員的學校接受培訓；已經工作了3年，其中2個是本科生研究項目； VB.NET中的數據採集/過程控制。用了1.5年的時間在VB6中的企業數據庫應用程序上工作。目前正在為具有2GB存儲，512MB RAM，500MHz x86 CPU的嵌入式 PC的項目工作；使用C ++同時運行的幾個應用程序，中間之間具有IPC機制。是的，我還年輕。

我的觀點：我認為，鑑於我上面編寫的環境，C ++可以有效地工作。誠然，硬實時性能不是我正在使用的應用程序的要求，在某些嵌入式應用程序中，這可能是個問題。但是，這是我學到的東西：

• C ++與C 根本不同（即，沒有C / C ++）。雖然所有有效的C語言都是有效的C ++語言，但C ++語言卻是一種截然不同的語言，需要學習如何使用C ++語言（而不是C語言）進行編程，以便在 any 情況下有效地使用它。在C ++中，您需要面向對象的程序，而不是程序性的程序，而不是兩者的混合（大型類具有很多功能）。通常，您應該集中精力製作具有很少功能的小型類，並將所有小型類組合成一個更大的解決方案。我的一位同事向我解釋說，我以前是在對像上進行過程編程的，這很麻煩，而且很難維護。當我開始應用更多的面向對象技術時，我發現代碼的可維護性/可讀性得到了提高。

• C ++以面向對象的開發形式提供了其他功能，這些功能可以提供簡化代碼以使其更易於閱讀/維護的方法。老實說，我認為在進行OOP時不會在性能/空間效率方面有所改進。但是我認為OOP是一種可以幫助將一個複雜的問題分解為許多小片段的技術。這對處理代碼的人員很有幫助，這個過程中不可忽略的元素。

• 許多反對C ++的參數主要與動態內存分配有關。 C也有同樣的問題。您可以編寫面向對象的應用程序而無需使用動態內存，儘管使用對象的好處之一是可以輕鬆地動態分配這些內容。就像在C語言中一樣，您必須注意如何管理數據以減少內存洩漏，但是 RAII技術在C ++中使這一過程變得更加簡單（通過將動態數據存儲器封裝在對像中來自動破壞它）。在某些應用程序中，每個內存位置都很重要，這可能太笨拙了，&難以管理。

編輯：

• WRT的“ Arduino C ++”問題：我認為沒有動態內存管理的C ++仍然有用。您可以將代碼組織到對像中，然後將這些對象放置在應用程序內的各個位置，設置回調接口等。既然我已經在C ++中進行開發，我可以看到在應用程序上分配了所有數據的多種方式。堆棧對於對象仍然有用。我會承認-我從未真正為Arduino編寫過這樣的嵌入式應用程序，因此我沒有任何依據。我有一些機會在即將到來的項目中進行一些Arduino開發-希望我可以在那裡測試我的主張。

是的，C ++的問題是代碼的佔用空間增加。

在某些系統中，您正在計算字節數，在這種情況下，您將不得不承受接近

但是，即使在C語言中，對於設計良好的系統，您也需要將所有內容封裝在一起。精心設計的系統很難，而C ++為程序員提供了一種結構化和受控的開發方法的場所。學習OOP是有成本的，如果您要切換到OOP，則您會接受它，並且在許多情況下，管理層寧願繼續使用C而不支付費用，因為很難衡量要轉換的結果。提高生產力。您可以在此處查看嵌入式系統專家Jack Ganssle的文章。

動態內存管理是魔鬼。並非如此，魔鬼是自動路由，動態內存管理在PC上運行良好，但是您可以期望至少每隔幾週重新啟動PC。 您會發現，隨著嵌入式系統持續運行5年，動態內存管理確實會搞砸，甚至開始出現故障。 Ganssle在他的文章中討論了堆棧和堆之類的問題。

C ++中的某些事情更容易引起問題並佔用大量資源，刪除動態內存管理和模板是使C ++的足跡更接近C足蹟的重要步驟。這仍然是C ++，您可以不需要動態內存管理或模板來編寫良好的C ++。我沒有意識到它們刪除了異常，我認為異常是我在發行版中刪除的代碼的重要組成部分，但直到那時才使用。在現場測試中，我可以讓異常生成消息來通知我異常被捕獲。

我認為萊納斯·托瓦爾茲（Linus Torvalds）的這種抗C ++特長很有趣。

C ++絕對最糟糕的功能之一是它如何使很多事情變得如此。上下文相關的-這僅意味著當您查看代碼時，本地視圖很少提供足夠的上下文來了解正在發生的情況。

他並不是在談論嵌入式系統世界，但是Linux內核開發。對我而言，相關性來自於此：C ++需要理解更大的上下文，並且我可以學習使用一組對像模板，我不相信自己會在幾個月後必須更新代碼時記住它們。 / p>

（另一方面，我目前正在使用Python（不是C ++，但使用相同的OOP範式）在嵌入式設備上工作，而這個問題確實存在。在我的辯護中，它是功能強大的嵌入式系統足以在10年前被稱為PC。）

我認為其他答案對於正反兩方面以及決策因素都非常有利，因此，我只想總結一下並添加一些評論。

對於小型微控制器（8位），沒有辦法。您只是要傷害自己，就沒有收穫，並且會浪費太多資源。

對於高端微控制器（例如，用於RAM和存儲的32位，10s或100s MB）

所以，問題是：邊界在哪裡？

我不確定，但是一旦我開發了一個帶有1 MB RAM的16位uC系統，&用C ++存儲了1 MB，後來就後悔了。是的，它行得通，但是我所付出的額外工作不值得。我必須使它適應，確保諸如異常之類的東西不會產生洩漏（OS + RTL支持非常錯誤且不可靠）。此外，OO應用程序通常會做很多小的分配，而這些應用程序的堆開銷又是另一個噩夢。

基於這種經驗，我假設在以後的項目中，我只會在至少16位且RAM &存儲至少16 MB的系統中選擇C ++。這是一個任意限制，並且可能會因應用程序類型，編碼樣式和習慣用法等因素而有所不同。但是，請注意，我建議採用類似的方法。

C ++的某些功能在嵌入式系統中很有用。還有其他一些例外情況，例如例外情況，可能會很昂貴，而且其代價可能並不總是很明顯。

如果我有德魯特人，那將會是一種流行的語言，它融合了兩全其美，兩種語言都缺少的一些功能；一些供應商提供了一些這樣的功能，但是沒有標準。我想看幾件事：

1. 類似於Java的異常處理，在異常處理中必須聲明可能引發或洩漏異常的函數。儘管從編程的角度來看，對此類聲明的要求可能會有些煩人，但如果函數可以成功返回任意整數，但也可能失敗，則可以提高代碼的清晰度。許多平台可以通過例如
2. 僅靜態和內聯函數的重載；在寄存器中具有返回值，在進位標誌中具有成功/失敗指示。我的理解是C的標準機構避免了函數重載，從而避免了名稱修飾。僅允許靜態和內聯函數的重載可以避免該問題，並且可以提供重載外部函數的99.9％的好處（因為.h文件可以根據名稱不同的外部函數來定義內聯重載）。特定的編譯時可解析常量參數值。當使用任何常量值傳遞時，某些函數可能非常高效地內聯，但是如果傳遞變量，則內聯性很差。其他時候，如果值恆定則可能是優化的代碼，如果不是則可能是悲觀的。例如：

    inline void copy_uint32s（uint32_t * dest，const uint32_t * src，__is_const int n）{if（n < = 0）return;否則，如果（n == 1）{dest [0] = src [0];}，否則，如果（n == 2）{dest [0] = src [0]; dest [1] = src [1];}
   否則，如果（n == 3）{dest [0] = src [0]; dest [1] = src [1]; dest [2] = src [2];}否則，如果（n == 4）{dest [0] = src [0]; dest [1] = src [1]; dest [2] = src [2]; dest [3] = src [3];}否則memcpy（（void *）dest，（const void *）src，n * sizeof（* src））;} 

   如果'n'可以在編譯時求值這段時間，上面的代碼比調用memcpy更有效，但是如果在編譯時無法評估'n'，則生成的代碼將比簡單地稱為memcpy的代碼更大，更慢。 ol>

   我知道C ++之父不太喜歡C ++的嵌入式版本，但是我認為它可以比僅使用C語言提供一些可觀的改進。

   任何人都知道是否有類似上面的內容正在考慮採用任何類型的標準嗎？

C ++不僅僅是一種編程語言：

a）是一種“更好的” Cb）是一種面向對象的語言c）這是一種允許我們編寫通用程序的語言

儘管所有這些功能都可以單獨使用，但是同時使用其中三個功能時，可以達到最佳效果。儘管如此，如果只選擇其中之一，嵌入式軟件的質量將會提高。

a）它是一種“更好的” C

C ++是一種強類型語言；比C語言更強大。您的程序將受益於此功能。

某些人擔心指針。 C ++包含了引用。重載的函數。

並且應該說：這些功能都不會出現在較大或較慢的程序中。

b）這是一種面向對象的語言

每當您準備使用微控制器的外設時，很可能外圍設備已經以設備驅動程序的形式為我們（從您自己或第三方）中提取。如我之前所說，該驅動程序使用C語法，如以下示例所示（直接取自NXP LPC1114示例）：

/ *定時器設置為TICKRATE_HZ進行匹配和中斷* /

Chip_TIMER_Reset（LPC_TIMER32_0）;

Chip_TIMER_MatchEnableInt（LPC_TIMER32_0，1）;

Chip_TIMER_SetMatch（LPC_TIMER32_0，1，（timerFreq / TICKRATE_Hatch_Patch_HZ2Enable]

Chip_TIMER_Enable（LPC_TIMER32_0）;

您看到抽象了嗎？因此，當出於相同目的使用C ++時，通過C ++的抽象和封裝機制將抽象提升到一個新的水平，

c）這是一種使我們能夠編寫通用程序的語言

通用程序是通過模板實現的，而且模闆對我們的程序也沒有任何成本。

靜態多態性

虛擬方法，RTTI和異常。

使用虛擬方法時存在一個折衷：更好的軟件而不是性能上的損失。但是，請記住，動態綁定可能使用虛擬表（函數指針數組）來實現。我已經在C中做了很多次（甚至是定期進行），所以我看不到使用虛擬方法的弊端。而且，C ++中的虛擬方法更加優雅。

最後，關於RTTI和異常的建議：不要在嵌入式系統中使用它們。不惜一切代價避免它們！！

我的背景是實時的（嵌入式（MCU，PC，UNIX，其他））。安全至上。我向STL介紹了一位前任雇主。我不再這樣做了。

某些火焰含量

C ++是否適合嵌入式系統？

嗯C ++是編寫的痛苦，也是維護的痛苦。 C +可以嗎（不要使用某些功能）

C ++在單片機中？實時操作系統？烤麵包機？還是嵌入式PC？

我還是說Meh。 C +並不太糟糕，但是ADA卻不那麼痛苦（這確實是在說些什麼）。如果像我這樣幸運的話，您可以使用嵌入式Java。經過檢查的數組訪問和無指針算法使得代碼非常可靠。嵌入式Java中的垃圾收集器並不是最高優先級，並且內存和對象的使用範圍很廣，因此設計良好的代碼可以在沒有GC的情況下永久運行。

OOP在微控制器上有用嗎？

可以。 UART是一個對象..... DMAC是一個對象...

對象狀態機非常簡單。

C ++是否會使程序員離硬件太遠而無法

除非它是PDP-11，否則不是CPU。 C ++最初是C語言的預處理器，因此Bjarne Stroustrup不會因為在AT&T.C ++上具有緩慢的Simula仿真而被嘲笑。C++不是您的CPU。

獲取運行Java字節碼的MCU。 Java程序。

應該將Arduino的C ++（沒有動態內存管理，模板，異常）視為“真正的C ++”嗎？

不。就像所有針對MCU的混蛋C編譯器一樣。

第四，嵌入式Java或嵌入式ADA已標準化。其他所有的都是悲傷。

嵌入式系統旨在執行某些特定任務，而不是用作執行多個任務的通用計算機。嵌入式系統是計算機硬件和軟件的組合。 C是所有現代語言的母親。雖然級別較低，但語言功能強大，並且可以處理各種硬件。因此，C / C ++是開發嵌入式系統軟件的最佳選擇，對於每個嵌入式系統來說，C / C ++都非常有用。眾所周知，C是一種開發語言。操作系統UNIX是用C編寫的。由於成功的軟件開發經常是為給定項目選擇最佳語言，因此令人驚訝的是發現C / C ++語言已證明自己適用於8位和64位處理器;在具有字節，千字節和兆字節內存的系統中。 C具有處理器獨立性的好處，它使程序員可以專注於算法和應用程序，而不是特定處理器體系結構的細節。但是，這些優點中的許多優點同樣適用於其他高級語言。但是C / C ++成功了，而其他許多語言卻大都失敗了？

<rant>

我首先認為C ++是一種糟糕的語言。如果要使用OOP，請編寫Java程序。 C ++不會執行OOP範例，因為直接內存訪問完全可以（濫用）能力來實現。

如果您有MCU，那麼您談論的是閃存容量可能不足100kB。您想用一種語言來編程，該語言的內存抽象為：當我聲明一個變量或數組時，它獲取內存，句點；應該或多或少禁止在嵌入式軟件中使用malloc（C ++中的“ new”關鍵字），除非在少數情況下在程序啟動過程中一次調用。在C語言還不夠底層的情況下進行編程，您需要執行一些操作，例如將變量分配給寄存器，並編寫內聯彙編以加強中斷服務例程（ISR）。諸如“ volatile”之類的關鍵字變得非常重要，需要理解。您花費大量時間在 bit 級別而不是 object 級別上操縱內存。

為什麼要自欺欺人地認為事情比實際上更簡單嗎？

< / rant>