組み込み開発にC ++ではなくCを使用する理由はありますか？
質問
ハードウェアC++とC89に2つのコンパイラがあります
私はクラスでC++を使用することを考えていますが、ポリモーフィズムはありません（vtableを避けるため）。 C++を使用する主な理由は次のとおりです。
- マクロ定義の代わりに「インライン」関数を使用することを好みます。
- コードを煩雑にするために名前空間を使用したいと思います。
- 主にテンプレートと冗長なキャストのために、C++の方が少し安全だと思います。
- オーバーロードされた関数とコンストラクター（自動キャストに使用）が本当に好きです。
非常に限られたハードウェア（4kbのRAM）向けに開発するときにC89を使い続ける理由はありますか？
結論
あなたの答えをありがとう、彼らは本当に役に立ちました！
私は主題を考えました、そして、私は主に次の理由でCに固執します：
- Cで実際のコードを予測するのは簡単です。これは、RAMが4kbしかない場合に非常に重要です。
- 私のチームは主にC開発者で構成されているため、高度なC++機能はあまり使用されません。
- Cコンパイラ（C89）で関数をインライン化する方法を見つけました。
たくさんの良い答えを提供したので、一つの答えを受け入れるのは難しいです。残念ながら、ウィキを作成して受け入れることはできないので、私が最も考えさせた答えを1つ選択します。
C++でCを使用する2つの理由：
- 多くの組み込みプロセッサでは、C++コンパイラがないか、追加料金を支払う必要があります。
- 私の経験では、組み込みソフトウェアエンジニアのかなりの割合は、C++の経験がほとんどないか、まったくない（1）か、電子工学の学位で教えられない傾向があるためです。彼らが知っていること。
また、元の質問といくつかのコメントでは、4 Kb of[〜＃〜] ram [〜＃〜]）に言及しています。一般的な組み込みプロセッサの場合、RAM=の量は、コードが格納され、フラッシュから実行されるため、（ほとんど）コードサイズとは無関係です。
確かに、コードストレージスペースの量は心に留めておくべきものですが、新しい、より容量の大きいプロセッサが市場に登場するので、最もコストに敏感なプロジェクトを除くすべてのプロジェクトで使用される問題ほど問題はありません。
組み込みシステムで使用するためのC++のサブセットの使用について： MISRA C++ 標準があります。これは一見の価値があります。
EDIT：この質問 も参照してください。これは、組み込みシステムのCとC++についての議論につながりました。
very4KBのRAMなどのリソースに制約のあるターゲットの場合、多くの労力をかける前にいくつかのサンプルで水域をテストします純粋なANSI C実装に簡単に移植できます。
Embedded C++ワーキンググループは、言語の標準サブセットと標準ライブラリの標準サブセットを提案しました。残念ながら、C User's Journalが亡くなったとき、私はその努力の軌跡を失いました。 Wikipedia に記事があり、 committee がまだ存在しているようです。
組み込み環境では、メモリの割り当てに注意する必要があります。この注意を強化するには、グローバルoperator new()とその友達をリンクさえできないものに定義して、使用されていないことがわかるようにする必要があります。一方、配置newは、安定した、スレッドセーフで、遅延が保証された割り当てスキームと共に賢明に使用される場合、あなたの友人である可能性があります。
インライン化された関数は、そもそも本当の関数でなければならないほど大きくない限り、あまり問題になりません。もちろん、それらを置き換えるマクロにも同じ問題がありました。
テンプレートも、インスタンス化がうまくいかない限り、問題を引き起こさないかもしれません。使用するテンプレートについては、生成したコードを監査し（リンクマップに十分な手がかりがある場合があります）、使用する予定のインスタンス化のみが行われたことを確認します。
発生する可能性があるもう1つの問題は、デバッガとの互換性です。それ以外の点で使用可能なハードウェアデバッガが、元のソースコードとの対話を非常に限定的にサポートすることは珍しいことではありません。アセンブリで効果的にデバッグする必要がある場合、C++の興味深い名前のマングリングにより、タスクにさらに混乱が生じる可能性があります。
RTTI、動的キャスト、多重継承、重度のポリモーフィズム、例外にはすべて、それらを使用するためのある程度のランタイムコストが伴います。これらの機能レベルのいくつかは、使用されるとプログラム全体にかかるコストがかかりますが、他の機能はそれらを必要とするクラスの重みを増やすだけです。違いを理解し、少なくとも大まかなコスト/利益分析の完全な知識を備えた高度な機能を賢明に選択します。
小規模な組み込み環境では、リアルタイムカーネルに直接リンクするか、ハードウェアで直接実行します。いずれにしても、ランタイムスタートアップコードがC++固有のスタートアップ作業を正しく処理することを確認する必要があります。これは正しいリンカーオプションを使用することを確認するのと同じくらい簡単かもしれませんが、ソースをパワーオンリセットエントリポイントに直接制御するのが一般的であるため、すべてを確実に行うためにそれを監査する必要があるかもしれません。たとえば、私が取り組んだColdFireプラットフォームでは、C++初期化子は存在するがコメントアウトされたCRT0.Sモジュールとともに開発ツールが出荷されました。ボックスから直接使用した場合、コンストラクターがまったく実行されなかったグローバルオブジェクトに戸惑いました。
また、組み込み環境では、ハードウェアデバイスを使用する前に初期化する必要がよくあります。OSとブートローダーがない場合、それを行うのはコードです。グローバルオブジェクトのコンストラクターが実行されることを覚えておく必要がありますbeforemain()が呼び出されるため、ローカルCRT0を変更する必要があります。グローバルコンストラクター自体が呼び出される前に、ハードウェアの初期化を完了するためのS（またはその同等物）before明らかに、main()の上部は遅すぎます。
いいえ。組み込み開発中は、問題（ランタイムポリモーフィズム、RTTIなど）を引き起こす可能性のあるC++言語機能を回避できます。組み込みC++開発者のコミュニティがあり（古いC/C++ユーザージャーナルでC++を使用して組み込み開発者がコラムを読んだことを覚えています）、選択がそれほど悪かった場合、彼らが非常に声高になるとは思いません。
C++のパフォーマンスに関するテクニカルレポート は、この種の優れたガイドです。組み込みプログラミングの問題に関するセクションがあることに注意してください！
また、回答のEmbedded C++についての++。私の好みに合わせて標準は100％ではありませんが、C++のどの部分を削除するかを決定する際の参考になります。
小規模なプラットフォーム向けのプログラミングでは、例外とRTTIを無効にし、仮想継承を回避し、存在する仮想関数の数に細心の注意を払いました。
ただし、あなたの友人はリンカーマップです。頻繁にチェックすると、コードのソースと静的メモリの膨張をすばやく見つけることができます。
その後、標準の動的メモリ使用の考慮事項が適用されます。言及した環境に制限されている環境では、動的割り当てをまったく使用しないこともできます。場合によっては、小さなダイナミックアロケート用のメモリプールや、ブロックを事前に割り当てて後ですべてを破棄する「フレームベース」の割り当てを回避できます。
C++コンパイラを使用することをお勧めしますが、C++固有の機能の使用を制限します。 C++でCのようにプログラムできます（C++を実行すると、Cランタイムが含まれますが、ほとんどの組み込みアプリケーションでは、とにかく標準ライブラリを使用しません）。
先に進んで、C++クラスなどを使用できます。
- 仮想関数の使用を制限する（あなたが言ったように）
- テンプレートの使用を制限する
- 組み込みプラットフォームの場合は、演算子newをオーバーライドするか、メモリ割り当てに配置newを使用します。
ファームウェア/組み込みシステムエンジニアとして、CがC++よりも1番上の選択である理由をいくつか説明できます。はい、両方に堪能です。
1）私たちが開発する一部のターゲットは、コードとデータの両方でRAMの64kBであるため、すべてのバイトカウントを確認する必要があります。それには2時間かかりましたが、それは2008年です。
2）すべてのCライブラリ関数は、サイズ制限のために最終コードに入れる前にレビューされます。したがって、divide（ハードウェアディバイダーがないため、大きなライブラリが必要です）、malloc（ヒープがないため） 、すべてのメモリは512バイトのチャンクでデータバッファから割り当てられ、コードを確認する必要があります）、または大きなペナルティを伴う他のオブジェクト指向のプラクティスです。使用するすべてのライブラリ関数がカウントされることを忘れないでください。
3）オーバーレイという用語を聞いたことがありますか？コードスペースが非常に小さいため、場合によっては別のコードセットと交換する必要があります。ライブラリ関数を呼び出す場合、ライブラリ関数は常駐する必要があります。オーバーレイ関数でのみ使用すると、オブジェクト指向のメソッドが多すぎて多くのスペースを無駄にします。そのため、Cライブラリ関数を仮定せず、C++を受け入れないでください。
4）ハードウェア設計が制限されている（つまり、特定の方法で配線されているECCエンジン）か、ハードウェアのバグに対処するために、キャスティングとパッキング（アライメントされていないデータ構造がワード境界を越える）が必要です。暗黙のうちに多くを仮定することはできません。なぜオブジェクトがそれを過度に指向するのでしょうか？
5）最悪の場合のシナリオ：オブジェクト指向メソッドの一部を削除すると、爆発する可能性のあるリソースを使用する前に開発を強制し（つまり、データバッファーからではなくスタックに512バイトを割り当てる）、潜在的な最悪のシナリオを回避します。コードパス全体をすべてテストすることも、排除することもありません。
6）多くの抽象化を使用して、ハードウェアをソフトウェアから保護し、コードを可能な限り移植可能にし、シミュレーションに適したものにします。ハードウェアアクセスは、異なるプラットフォーム間で条件付きでコンパイルされるマクロまたはインライン関数でラップする必要があり、データ型はターゲット固有ではなくバイトサイズとしてキャストする必要があり、直接ポインターの使用は許可されません（一部のプラットフォームではメモリマップI/Oが想定されるためデータメモリと同じ）など.
私はもっと考えることができますが、あなたはアイデアを得る。私たちのファームウェア担当者はオブジェクト指向のトレーニングを行っていますが、組み込みシステムのタスクはハードウェア指向で低レベルであるため、本来は高レベルでも抽象化もできません。
ところで、私がこれまで行ってきたすべてのファームウェアジョブはソース管理を使用していますが、そのアイデアをどこから得ているのかわかりません。
-SanDiskのファームウェアガイ。
私の個人的な好みはCです：
- 私はすべてのコード行が何をしているのかを知っています（そしてコスト）
- すべてのコード行が何をしているのか（そしてコスト）を知るのに十分なほどC++を知らない
なぜ人々はこれを言うのですか？ do n't asmの出力を確認しない限り、Cのすべての行が何をしているのかを知っています。 C++についても同様です。
たとえば、この無邪気な文が生成するasmは次のとおりです。
a[i] = b[j] * c[k];
それはかなり無害に見えますが、gccベースのコンパイラは8ビットマイクロ用にこのasmを生成します
CLRF 0x1f, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1f, F, ACCESS
MOVWF 0x1e, ACCESS
MOVLW 0xf9
MOVF 0xfdb, W, ACCESS
ADDWF 0x1e, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfa
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1f, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x1c
NOP
MOVFF 0xfef, 0x1d
NOP
MOVLW 0x1
CLRF 0x1b, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1b, F, ACCESS
MOVWF 0x1a, ACCESS
MOVLW 0xfb
MOVF 0xfdb, W, ACCESS
ADDWF 0x1a, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfc
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1b, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x18
NOP
MOVFF 0xfef, 0x19
NOP
MOVFF 0x18, 0x8
NOP
MOVFF 0x19, 0x9
NOP
MOVFF 0x1c, 0xd
NOP
MOVFF 0x1d, 0xe
NOP
CALL 0x2142, 0
NOP
MOVFF 0x6, 0x16
NOP
MOVFF 0x7, 0x17
NOP
CLRF 0x15, ACCESS
RLCF 0xfdf, W, ACCESS
ANDLW 0xfe
RLCF 0x15, F, ACCESS
MOVWF 0x14, ACCESS
MOVLW 0xfd
MOVF 0xfdb, W, ACCESS
ADDWF 0x14, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfe
MOVF 0xfdb, W, ACCESS
ADDWFC 0x15, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0x16, 0xfee
NOP
MOVFF 0x17, 0xfed
NOP
生成される命令の数は、以下に大きく依存します。
- A、b、およびcのサイズ。
- それらのポインターがスタックに格納されているか、グローバルであるか
- i、j、kがスタック上にあるか、グローバルであるか
これは、プロセッサがCを処理するように設定されていない小さな組み込みの世界で特に当てはまります。したがって、asm出力を常に調べない限り、CとC++は互いに同じくらい悪いという答えになります。互いに同じくらい良いです。
ヒューゴ
生成される実際のコードをより簡単に予測できるため、組み込み作業にCを好む人もいると聞きました。
個人的には、CスタイルのC++を書く（型安全のためのテンプレートを使用する）ことで多くの利点が得られると思いますが、そうしない本当の理由はわかりません。
C++の代わりにCを使用する理由はありません。 Cでできることは何でも、C++でもできます。 VMTのオーバーヘッドを回避したい場合は、仮想メソッドとポリモーフィズムを使用しないでください。
ただし、C++はオーバーヘッドのない非常に便利なイディオムを提供できます。私のお気に入りの1つはRAIIです。クラスはメモリやパフォーマンスの点で高価ではありません...
IAR WorkbenchでARM7組み込みpaltformのコードをいくつか作成しました。テンプレートを使用して、コンパイル時の最適化とパス予測を行うことを強くお勧めします。ペストのような動的なキャストを避けます。 Andrei Alexandrescuの本、 Modern C++ design で規定されているように、特性/ポリシーを有利に使用してください。
学ぶのは難しいかもしれませんが、あなたの製品がこのアプローチの恩恵を受けることも確信しています。
4KのRAMに制約されたシステムの場合は、C++ではなくCを使用して、進行中のすべてを確実に確認できるようにします。 C++の利点は、コードを一見するよりもはるかに多くのリソース（CPUとメモリの両方）を使用するのが非常に簡単なことです。 （ああ、それを行うために別のBlerfObjectを作成します...メモリ不足です！）
既に述べたように（RTTIなし、vtableなしなど）、C++で行うことができますが、C++で使用するのと同じように、C++の使用が逃げないようにするのに十分な時間を費やします。 。
正当な理由で、時には唯一の理由は、特定の組み込みシステム用のC++コンパイラがまだないことです。これは、たとえば Microchip PIC マイクロコントローラの場合です。書くのはとても簡単で、無料のCコンパイラ（実際にはCのわずかなバリアント）がありますが、C++コンパイラはありません。
人間の心は、可能な限り評価し、次に焦点を合わせることが重要であるものを決定し、残りを破棄または減価償却することによって複雑さを扱います。これは、マーケティングのブランディングの背後にある全体的な基盤であり、主にアイコンです。
この傾向に対抗するために、私はC++よりもCの方が好きです。コードについて、そしてハードウェアとどのように密接にやり取りするのかを考えさせられるからです。
長い経験から、Cは問題のより良い解決策をあなたに強制することを強制していると信じています。部分的には、あなたの邪魔をせず、コンパイラーライターが良いアイデアだと思った制約を満たすために多くの時間を浪費させないことです、または「カバーの下で」何が起こっているかを把握します。
そのように、Cのような低レベル言語では、ハードウェアに焦点を当てて適切なデータ構造/アルゴリズムバンドルを構築するのに多くの時間を費やしますが、高レベル言語では、そこで何が起こっているのかと頭を悩ませる時間がかかります、そしてあなたがあなたの特定の文脈と環境で完全に合理的なことをできない理由。コンパイラーを打ち負かすこと（強い型付けは最悪の違反者です）は、時間の生産的な使用ではありません。
私はおそらくプログラマーの型にうまくフィットします-私はコントロールが好きです。私の見解では、それはプログラマーの人格の欠陥ではありません。コントロールは、私たちが行うために支払われるものです。より具体的には、FLAWLESSLY制御。 Cは、C++よりもはるかに多くの制御を提供します。
個人的には4kbのメモリで、C++からそれほど多くのマイレージを取得していないと思いますので、言語はおそらく重要ではないので、ジョブに最適なコンパイラ/ランタイムの組み合わせと思われるものを選択してください。
とにかく言語もすべてではないことに注意してください。なぜなら、ライブラリも重要だからです。多くの場合、Cライブラリの最小サイズはわずかに小さくなりますが、組み込み開発を対象としたC++ライブラリは削減されると想像できますので、必ずテストしてください。
Cコンパイラーは高度なC++機能をサポートする必要がないため、Cコンパイラーがはるかに効率的なコードを生成できるため、最適化をより積極的に行えると言う人もいます。
もちろん、この場合、2つの特定のコンパイラーをテストすることもできます。
非常に限られたハードウェア（4kbのRAM）向けに開発するときにC89を使い続ける理由はありますか？
個人的には、組み込みアプリケーションに関しては（組み込みと言うとき、winCE、iPhoneなどを意味するものではありません。今日の組み込みデバイスは肥大化しています）。リソースが限られたデバイスを意味します。私はCを好みますが、私はC++でもかなり働いています。
たとえば、あなたが話しているデバイスには4kbのRAMがあります。そのため、C++を検討しません。もちろん、他の投稿が示唆しているように、C++を使用して小さなものを設計し、アプリケーションでの使用を制限できる場合がありますが、C++は潜在的にアプリケーションを複雑化/膨張させる可能性があります。
静的にリンクしますか？ c ++とcを使用して、静的なダミーアプリケーションを比較することができます。そのため、代わりにCを検討することになります。一方、メモリ要件内でC++アプリケーションを構築できる場合は、それを試してください。
私見、一般に、組み込みアプリケーションでは、私は起こっているすべてを知りたいです。誰がメモリ/システムリソースを使用していますか？それらはいつ解放されますか？
X量のリソース、CPU、メモリなどでターゲットを開発する場合、将来の要件がどうなるかわからないので、それらのリソースを使用することは避けてください。単純な小さなアプリケーションであると「想定」されていましたが、はるかに大きくなります。
私の選択は通常、使用するCライブラリによって決まります。Cライブラリは、デバイスが何をする必要があるかに基づいて選択されます。だから、9/10回.. uclibcまたはnewlibとCになります。使用するカーネルもこれに大きな影響を与えます。または、独自のカーネルを作成している場合も同様です。
また、共通基盤の選択。ほとんどの優秀なCプログラマーは、C++を使用しても問題はありません（多くの人が使用していると文句を言っていますが）..（私の経験では）逆のことが当てはまるとは思いません。
私たちが取り組んでいるプロジェクト（ゼロアップカーネルを含む）では、ほとんどのことはCで行われますが、C++を使用してネットワークを実装する方が簡単で問題が少ないため、小さなネットワークスタックがC++で実装されました。
最終的に、デバイスは動作し、受け入れテストに合格するか、合格しません。 xxスタックでfooを実装し、言語zを使用してyyヒープ制約を実装できる場合は、それを使用して、生産性を高めるものを使用します。
私の個人的な好みはCです：
- 私はすべてのコード行が何をしているのかを知っています（そしてコスト）
- すべてのコード行が何をしているのか（そしてコスト）を知るのに十分なほどC++を知らない
はい、私はC++に慣れていますが、標準Cのようにそれを知りません。
今、あなたがその逆を言うことができるなら、よく、あなたが知っているものを使用してください:)それが機能する場合、テストに合格するなど、問題は何ですか？
Cは移植性で勝ちます-言語仕様のあいまいさが少ないためです。したがって、さまざまなコンパイラなどでの移植性と柔軟性が大幅に向上します（頭痛が少なくなります）。
ニーズを満たすためにC++機能を利用しない場合は、Cを使用してください。
ROM/FLASHはどれくらいありますか？
4kBのRAMは、実際のコードと静的データを保存するために数百キロバイトのフラッシュがあることを意味します。このサイズのRAMは変数のみを意味する傾向があり、それらに注意すれば、コード行の点でかなり大きなプログラムをメモリに収めることができます。
ただし、C++は、オブジェクトの実行時の構築規則のために、FLASHにコードとデータを配置することをより困難にする傾向があります。 Cでは、定数構造体を簡単にフラッシュメモリに配置し、ハードウェア定数オブジェクトとしてアクセスできます。 C++では、定数オブジェクトはコンパイラがコンパイル時にコンストラクタを評価することを必要としますが、これはまだC++コンパイラができることを超えていると思います（理論的にはあなたはそれを行うことができますが、実際には非常に難しいです） 。
だから、「小さなRAM」、「大きなフラッシュ」のような環境では、私はいつでもCを使います。クラスベースではないコード用のニースC++機能のほとんどを備えたC99の良い中間選択に注意してください。
C IMHOを好む唯一の理由は、プラットフォームのC++コンパイラが適切な形になっていない場合（バグがある、最適化が不十分など）です。
「UNLIMITED」リソースを持つシステムは存在しないと言いたいだけです。この世界のすべては限られており、すべてのアプリケーションは、ASM、C、JavaまたはJavaScript。 、Pixelおよびその他のデバイスは非常に動きが遅くなります。
しかし、リソースの浪費に反対する別の側面から-それらのリソースを節約するのにかかる時間です。既に実装、テスト、配布されているC++を使用する代わりに、Cで簡単なことを書いて数ティックと数バイトを節約するのに1週間余分にかかる場合。なぜわざわざ？ USBハブを購入するようなものです。はい、あなたは自分でそれを作ることができますが、それは良くなるでしょうか？より信頼できる？時間を数えると安くなりますか？
ちょっと考えてみてください-コンセントからの電力も無制限ではありません。それがどこから来たのかを調べてみてください。何かを燃やしているのがほとんどです。エネルギーと物質の法則はまだ有効です。物質もエネルギーも現れたり消えたりするのではなく、変化します。
C99にインラインがあります。たぶん、あなたは俳優が好きですが、dtorsを正しくするビジネスは面倒です。 Cを使用しない残りの唯一の理由が名前空間の場合、私は本当にC89に固執します。これは、わずかに異なる組み込みプラットフォームに移植したい場合があるためです。後で同じコードでC++で記述を開始できます。ただし、C++はCのスーパーセットではありません。次の点に注意してください。C89コンパイラを持っていると言いましたが、とにかくC99とC++の比較を行います。
sizeof 'a'> 1（C++ではなくC）。 Cには、VLA可変長配列があります。例：func（int i）{int a [i]。 Cには、VAM変数配列メンバーがあります。例：struct {int b; int m [];}。
一般的にはありませんC++はCのスーパーセットです。これは、特に新しいプロジェクトに当てはまります。
CPU時間とメモリフットプリントの点で高価になる可能性のあるC++コンストラクトを回避するのは正しい方向に進んでいます。
多型のようなものは非常に価値があることに注意してください-これらは本質的に関数ポインタです。必要な場合は、賢く使用してください。
また、優れた（適切に設計された）例外処理により、組み込みアプリは、従来のエラーコードで処理するアプリよりも信頼性が高くなります。
本 C++ for Game Programmers には、C++の機能に基づいてコードサイズが増加する時期に関する情報があります。
メモリ割り当ての問題については、Quantum Platformとそのステートマシンアプローチを使用することをお勧めします。初期化時に必要なものはすべて割り当てられるためです。また、競合の問題を軽減するのにも役立ちます。
この製品は、CとC++の両方で実行されます。
質問の異なる側面に対する異なる回答の投稿：
「malloc」
以前のいくつかの回答では、これについてかなり話しています。なぜあなたはコールが存在するとさえ思いますか？本当に小さなプラットフォームの場合、mallocは使用できないか、または間違いなくオプションになる傾向があります。動的メモリ割り当ての実装は、システムの下部にRTOSがある場合に意味がありますが、それまでは純粋に危険です。
あなたはそれなしで非常に遠くまで行くことができます。ローカル変数のための適切なスタックさえ持っていないすべての古いFORTRANプログラムについて考えてみてください...
コンパイラに依存します。
すべての組み込みコンパイラがすべてのC++を実装しているわけではありません。実装されていても、コードの肥大化を回避するのは得策ではありません（テンプレートでは常にリスクです）。いくつかの小さなプログラムでテストし、問題が発生するかどうかを確認します。
しかし、goodコンパイラを指定した場合、いいえ、C++を使用しない理由はありません。
組み込み開発にISO C++を使用する方法の例を見つけました。これは、C++またはCを使用するたびに決定を下す人にとって興味深いものです。
Bjarne Stroustrupによって提供されました 彼のホームページで ：
本格的な組み込みシステムプログラミングにISO C++を使用する方法については、 JSF air vehicle C++コーディング標準 をご覧ください。
世界中にはさまざまなコントローラメーカーが存在し、それらの設計と、構成に使用する必要がある命令セットを確認すると、多くの問題が発生する可能性があります。アセンブリ言語の主な欠点は、マシン/アーキテクチャに依存することです。開発者がさまざまなコントローラーのコーディングを達成するためにそこに設定されているすべての指示を暗記することは本当に大きな要請です。これが、Cがハードウェア依存の詳細からアルゴリズムとデータ構造を抽象化するのに十分な高レベルであり、さまざまなターゲットハードウェア、アーキテクチャに依存しない言語、および非常に簡単にソースコードを移植できるため、組み込み開発でCがより普及した理由ですコードを変換して保守します。しかし、C、C++、Python、Javaなど）などの一部の高レベル言語（オブジェクト指向）は、組み込みシステム開発の監視下で十分に進化していることがわかります。