組み込み開発に C++ ではなく C を使用する理由はありますか?

Question

質問

私のハードウェアには C++ と C89 の 2 つのコンパイラがあります

クラスを使用して C++ を使用することを考えていますが、(vtable を避けるために) ポリモーフィズムは使用しません。私が C++ を使用したい主な理由は次のとおりです。

• 私はマクロ定義の代わりに「インライン」関数を使用することを好みます。
• 接頭辞があるとコードが煩雑になるため、名前空間を使用したいと考えています。
• C++ は主にテンプレートと冗長キャストのおかげで、少しタイプセーフになっていると思います。
• 私はオーバーロードされた関数とコンストラクター (自動キャストに使用される) がとても好きです。

非常に限られたハードウェア (4kb の RAM) で開発する場合に C89 にこだわる理由はありますか?

結論

ご回答ありがとうございます。本当に役に立ちました。

私はこのテーマについてよく考えましたが、主に次の理由から C を使い続けることにしました。

1. C では実際のコードを予測する方が簡単で、RAM が 4kb しかない場合、これは非常に重要です。
2. 私のチームは主に C 開発者で構成されているため、高度な C++ 機能は頻繁に使用されません。
3. C コンパイラ (C89) で関数をインライン化する方法を見つけました。

非常に多くの良い回答を提供していただいたので、1 つの回答を受け入れるのは困難です。残念ながら Wiki を作成して受け入れることはできないので、最も考えさせられた回答を 1 つ選択します。

Answer 1

C ++でCを使用する2つの理由：

1. 多くの組み込みプロセッサでは、C ++コンパイラがないか、追加料金を支払う必要があります。
2. 私の経験では、組み込みソフトウェアエンジニアのかなりの割合が、C ++の経験がほとんどないか、まったくない（1）か、電子工学の学位で教えられない傾向があるためです。彼らが知っていることに固執する。

また、元の質問といくつかのコメントには、 RAM の4 KBが記載されています。典型的な組み込みプロセッサの場合、コードが保存され、フラッシュから実行されるため、RAMの量は（ほとんど）コードサイズとは無関係です。

確かに、コードストレージスペースの量は念頭に置く必要がありますが、新しい、より容量の大きいプロセッサが市場に登場するので、最もコストに敏感なプロジェクトを除くすべてのプロジェクトに使用されるよりも問題は少なくなります。

組み込みシステムで使用するためのC ++のサブセットの使用： MISRA C ++ 標準、一見の価値があるかもしれません。

編集： この質問も参照してください。これにより、組み込み向けのCとC ++についての議論が始まりました。システム。

Answer 2

4KBのRAMなどの非常にのリソース制約のあるターゲットの場合、純粋なANSI Cに簡単に移植できない多くの努力をする前に、いくつかのサンプルで水域をテストします実装。

Embedded C ++ワーキンググループは、言語の標準サブセットと標準ライブラリの標準サブセットを提案しました。残念ながら、C User's Journalが亡くなったとき、私はその努力の軌跡を失いました。 Wikipedia に記事があり、委員会はまだ存在しています。

組み込み環境では、メモリの割り当てに注意する必要があります。その注意を強めるために、グローバルな operator new（）とその友達をリンクさえできないものに定義して、使用されていないことがわかるようにする必要があるかもしれません。一方、安定した、スレッドセーフで、遅延が保証された割り当てスキームとともに慎重に使用すると、配置 new は友人になる可能性があります。

インライン化された関数は、そもそも本当の関数でなければならないほど大きくない限り、あまり問題になりません。もちろん、置き換えるマクロにも同じ問題がありました。

テンプレートも、インスタンス化が正常に実行されない限り、問題を引き起こすことはありません。使用するテンプレートについては、生成したコードを監査し（リンクマップに十分な手がかりがある場合があります）、使用する予定のインスタンス化のみが発生したことを確認します。

発生する可能性があるもう1つの問題は、デバッガとの互換性です。それ以外の点で使用可能なハードウェアデバッガが、元のソースコードとの対話を非常に限定的にサポートすることは珍しいことではありません。アセンブリで効果的にデバッグする必要がある場合、C ++の興味深い名前のマングリングにより、タスクにさらに混乱が生じる可能性があります。

RTTI、動的キャスト、多重継承、重度のポリモーフィズム、および例外はすべて、それらの使用にある程度のランタイムコストが伴います。これらの機能レベルのいくつかは、使用されるとプログラム全体にかかるコストがかかりますが、他の機能はそれらを必要とするクラスの重みを増やすだけです。違いを把握し、少なくとも大まかなコスト/利益分析の完全な知識を備えた高度な機能を賢明に選択します。

小規模な組み込み環境では、リアルタイムカーネルに直接リンクするか、ハードウェアで直接実行します。いずれにしても、ランタイムスタートアップコードがC ++固有のスタートアップ作業を正しく処理することを確認する必要があります。これは正しいリンカーオプションを使用することを確認するのと同じくらい簡単かもしれませんが、ソースをパワーオンリセットエントリポイントに直接制御するのが一般的であるため、すべてを確実に実行するためにそれを監査する必要があるかもしれません。たとえば、私が取り組んだColdFireプラットフォームでは、C ++初期化子は存在するがコメントアウトされたCRT0.Sモジュールとともに開発ツールが出荷されました。ボックスから直接使用した場合、コンストラクターがまったく実行されなかったグローバルオブジェクトに戸惑うことになります。

また、組み込み環境では、ハードウェアデバイスを使用する前に初期化する必要がよくあります。OSとブートローダーがない場合は、それを行うのがコードです。グローバルオブジェクトのコンストラクターは main（）が呼び出される前に実行されるので、ローカルCRT0.S（またはそれに相当するもの）を変更して取得する必要があることを覚えておく必要があります。ハードウェアの初期化は、グローバルコンストラクター自体が呼び出される前に 行われます。明らかに、 main（）の先頭は手遅れです。

Answer 3

いいえ。問題を引き起こす可能性のある C++ 言語機能 (ランタイム ポリモーフィズム、RTTI など) は、組み込み開発中に回避できます。組み込み C++ 開発者のコ​​ミュニティがあり (古い C/C++ ユーザー ジャーナルで C++ を使用する組み込み開発者によるコラムを読んだことを覚えています)、もしその選択がそれほど悪いものであれば、彼らがそれほど声高に言うとは想像できません。

Answer 4

C ++パフォーマンスに関する技術レポートはこの種のことのための素晴らしいガイド。組み込みプログラミングの問題に関するセクションがあることに注意してください！

また、回答でのEmbedded C ++の言及に関する++。規格は私の好みに100％準拠しているわけではありませんが、C ++のどの部分を削除するかを決定する際の参考になります。

小規模なプラットフォーム向けのプログラミング中は、例外とRTTIを無効にし、仮想継承を回避し、存在する仮想関数の数に細心の注意を払いました。

ただし、あなたの友人はリンカーマップです。頻繁にチェックしてください。コードのソースと静的メモリの膨張をすばやく見つけることができます。

その後、標準の動的メモリ使用に関する考慮事項が適用されます。言及した環境に制限されている環境では、動的割り当てをまったく使用しないこともできます。場合によっては、小さな動的allocのメモリプール、または「フレームベース」を回避できます。ブロックを事前に割り当て、後ですべてを捨てる割り当て。

Answer 5

C ++コンパイラの使用をお勧めしますが、C ++固有の機能の使用を制限します。 C ++でCのようにプログラムできます（C ++を実行すると、Cランタイムが含まれますが、ほとんどの組み込みアプリケーションでは、とにかく標準ライブラリを使用しません）。

先に進み、C ++クラスなどを使用できます。

• （先ほど言ったように）仮想関数の使用を制限する
• テンプレートの使用を制限する
• 組み込みプラットフォームの場合は、演算子newをオーバーライドするか、メモリ割り当てに配置newを使用します。

Answer 6

ファームウェア/組み込みシステムエンジニアとして、CがC ++よりも1番上の選択である理由のいくつかを皆さんに伝えることができます。はい、私はそれらの両方に堪能です。

1）私たちが開発する一部のターゲットは、コードとデータの両方に64kBのRAMを持っているため、すべてのバイトカウントを確認する必要があります。はい、2時間かかる4バイトを節約するコード最適化に対処しました。それは2008年です。

2）サイズ制限のため、すべてのCライブラリ関数は最終コードに入れる前にレビューされるため、divide（ハードウェアディバイダーがないため、大きなライブラリが必要です）、malloc（ヒープがない場合、すべてのメモリは512バイトのチャンクでデータバッファから割り当てられ、コードを確認する必要があります）、または大きなペナルティを伴う他のオブジェクト指向のプラクティスです。使用するすべてのライブラリ関数がカウントされることを忘れないでください。

3）オーバーレイという用語を聞いたことがありますか？コードスペースが非常に小さいため、別のコードセットと交換する必要がある場合があります。ライブラリ関数を呼び出す場合、ライブラリ関数は常駐する必要があります。オーバーレイ関数でのみ使用する場合、オブジェクト指向のメソッドが多すぎるため、多くのスペースを無駄にしています。したがって、Cライブラリ関数を想定せず、C ++は受け入れないでください。

4）ハードウェア設計が制限されている（つまり、特定の方法で配線されているECCエンジン）ため、またはハードウェアのバグに対処するために、キャストとパッキング（アライメントされていないデータ構造がワード境界を越える）が必要です。暗黙的に想定しすぎることはできないので、なぜオブジェクトの向きを決めすぎるのですか？

5）最悪のシナリオ：オブジェクト指向のメソッドの一部を削除すると、爆発する可能性のあるリソースを使用する前に開発を強制し（つまり、データバッファーからではなくスタックに512バイトを割り当て）、潜在的な最悪の事態を防ぎますテストされていない、またはコードパス全体を一緒に排除しないケースシナリオ。

6）ハードウェアをソフトウェアから遠ざけ、コードを可能な限り移植可能にし、シミュレーションに適したものにするために、多くの抽象化を使用します。ハードウェアアクセスは、異なるプラットフォーム間で条件付きでコンパイルされるマクロまたはインライン関数でラップする必要があり、データ型はターゲット固有ではなくバイトサイズとしてキャストする必要があり、直接ポインターの使用は許可されません（一部のプラットフォームではメモリマップI / Oが想定されるためデータメモリと同じ）など。

もっと考えることはできますが、あなたはそのアイデアを得ます。私たちのファームウェア担当者はオブジェクト指向のトレーニングを行っていますが、組み込みシステムのタスクはハードウェア指向で低レベルであるため、本質的に高レベルでも抽象化もできません。

ところで、私がこれまでに行ったすべてのファームウェアジョブはソース管理を使用していますが、どこからそのアイデアを得ているのかわかりません。

-SanDiskのファームウェアガイ。

Answer 7

  

個人的な好みはCです。理由は

     

  
• すべてのコード行が何をしているのか（そしてコスト）を知っている
  
• コードのすべての行が何をしているのか（およびコスト）を知るのに十分なC ++の知識がありません
  

なぜこれを言うのですか？ 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を処理するように設定されていない小さな組み込みの世界で特に当てはまります。したがって、私の答えは、その場合、それらは互いに同等に優れています。

ヒューゴ

Answer 8

組み込み作業にCを好む人がいると聞いたことがあります。これは、生成される実際のコードをより簡単に予測できるためです。

個人的には、C型C ++を書く（型安全のためのテンプレートを使用する）ことで多くの利点が得られると思いますが、そうしない本当の理由はわかりません。

Answer 9

C ++の代わりにCを使用する理由はありません。 Cでできることは何でも、C ++でもできます。 VMTのオーバーヘッドを回避する場合は、仮想メソッドとポリモーフィズムを使用しないでください。

ただし、C ++はオーバーヘッドのない非常に便利なイディオムを提供できます。私のお気に入りの1つはRAIIです。クラスはメモリやパフォーマンスの点で高価ではありません...

Answer 10

IAR Workbench で ARM7 組み込み paltform 用のコードをいくつか書きました。コンパイル時の最適化とパス予測を行うには、テンプレートに依存することを強くお勧めします。疫病のような動的なキャストは避けてください。アンドレイ・アレクサンドルスクの本に規定されているように、特性やポリシーを有利に利用してください。 最新の C++ 設計.

学ぶのが難しいかもしれないことは承知していますが、あなたの製品がこのアプローチから恩恵を受けることも確信しています。

Answer 11

正当な理由で、時には唯一の理由は、特定の組み込みシステム用のC ++コンパイラがまだないことです。これは、たとえば Microchip PIC マイクロコントローラーの場合です。書くのは非常に簡単で、無料のCコンパイラ（実際にはCのわずかなバリアント）がありますが、C ++コンパイラはありません。

Answer 12

4KのRAMに制約されたシステムの場合は、C ++ではなくCを使用します。これは、進行中のすべてを確実に確認できるようにするためです。 C ++の利点は、コードを一見するよりもはるかに多くのリソース（CPUとメモリの両方）を使用するのが非常に簡単なことです。 （ああ、それを行うために別のBlerfObjectを作成します...メモリ不足です！）

既に述べたように（RTTIなし、vtableなしなど）、C ++で実行できますが、C ++の使用があなたから逃げないようにするのに十分な時間を費やしますCで同等。

Answer 13

人間の心は、可能な限り評価し、焦点を合わせることが重要なことを決定し、残りを破棄または減価償却することにより、複雑さを扱います。これは、マーケティングにおけるブランディングの背後にある全体的な基盤であり、主にアイコンです。

この傾向に対抗するために、私はC ++よりもCの方が好きです。なぜなら、それはコードについて、そしてハードウェアとより密接に-容赦なく密接に相互作用する方法について考えることを強いるからです。

長年の経験から、Cは問題のより良い解決策を考え出すことを強いられると信じています良いアイデア、または「カバーの下で」何が起こっているかを把握する。

そのように、Cのような低レベル言語では、ハードウェアに焦点を当てて、適切なデータ構造/アルゴリズムバンドルを構築するのに多くの時間を費やしますが、高レベル言語では、そこに、そしてあなたがあなたの特定のコンテキストと環境で完全に合理的なことをできない理由。コンパイラーを打ち負かすこと（強いタイピングは最悪の違反者です）は時間の生産的な使用ではありません。

私はおそらくプログラマーの型にうまくフィットします-私はコントロールが好きです。私の考えでは、それはプログラマーの性格の欠陥ではありません。コントロールは、私たちが行うために支払われるものです。より具体的には、FLAWLESSLY制御。 CはC ++よりもはるかに制御しやすくなります。

Answer 14

個人的に4kbのメモリでは、C ++からそれほど多くのマイレージを取得していないと思いますので、言語はおそらく重要ではないので、ジョブに最適なコンパイラ/ランタイムの組み合わせと思われるものを選択してください。

ライブラリも重要なので、とにかく言語についてのすべてではないことに注意してください。多くの場合、Cライブラリの最小サイズはわずかに小さくなりますが、組み込み開発を対象としたC ++ライブラリは削減されると想像できますので、必ずテストしてください。

Answer 15

Cコンパイラは、高度なC ++機能をサポートする必要がないため、最適化をより積極的に行えるため、Cコンパイラははるかに効率的なコードを生成できると言う人もいます。

もちろん、この場合、2つの特定のコンパイラーをテストすることもできます。

Answer 16

Cは移植性で勝ちます-言語仕様のあいまいさが少ないためです。そのため、さまざまなコンパイラなどでの移植性と柔軟性が大幅に向上します（頭痛が少なくなります）。

必要に応じてC ++機能を活用しない場合は、Cを使用します。

Answer 17

  

ごく限られた開発のためにC89に固執する理由はありますか   ハードウェア（4kbのRAM）？

個人的には、組み込みアプリケーションに関して言えば（組み込みと言うとき、私はwinCEやiPhoneなどを意味しません。今日の組み込みデバイスは肥大化しています）。リソースが限られたデバイスを意味します。 私はCを好みますが、私はC ++でもかなり働いています。

たとえば、あなたが話しているデバイスには 4kb のRAMがあります。そのため、C ++は考慮しません。確かに、C ++を使用して小さなものを設計し、他の投稿が示唆しているようにアプリケーションでの使用を制限できるかもしれませんが、C ++は「できません」。潜在的にアプリケーションを複雑化/肥大化させることになります。

静的にリンクしますか？ c ++とcを使用して、静的なダミーアプリケーションを比較することができます。そのため、代わりにCを検討することになります。一方、メモリ要件内でC ++アプリケーションを構築できる場合は、それを試してください。

私見、 一般に、組み込みアプリケーションでは、進行中のすべてを知るのが好きです。誰がメモリ/システムリソースを使用していますか？彼らはいつそれらを解放しますか？

X量のリソース、CPU、メモリなどを備えたターゲット用に開発する場合、将来の要件がどうなるかわからないため、これらのリソースを使用することは避けてください。 「想定」されたプロジェクトシンプルで小さなアプリケーションになりますが、最終的にははるかに大きくなります。

Answer 18

通常、私の選択は、使用するCライブラリによって決定されます。Cライブラリは、デバイスが何をする必要があるかに基づいて選択されます。だから、9/10回.. uclibcまたはnewlibとCになります。使用するカーネルもこれに大きな影響を及ぼします。または、独自のカーネルを作成している場合もあります。

これは、共通基盤の選択でもあります。ほとんどの優秀なCプログラマーはC ++を使用しても問題はありません（多くの人が使用していると文句を言っていますが）。しかし、私はその逆が正しいとは思いません（私の経験では）。

私たちが取り組んでいるプロジェクト（ゼロからのカーネルを含む）では、ほとんどのことはCで行われますが、C ++を使用してネットワークを実装する方が簡単で問題が少ないため、小さなネットワークスタックがC ++で実装されました。

最終的な結果として、デバイスは動作し、受け入れテストに合格するか、合格しません。言語xxを使用してxxスタックおよびyyヒープ制約にfooを実装できる場合は、それを使用して、生産性を高めるものを使用してください。

個人的な好みはCです。理由は

• すべてのコード行が何をしているのか（そしてコスト）を知っている
• コードのすべての行が何をしているのか（およびコスト）を知るのに十分なC ++の知識がありません

はい、私はC ++に慣れていますが、標準Cを行うのと同じようにそれを知りません。

今、その逆を言うことができれば、あなたが知っていることを使用してください:)それが機能する場合、テストに合格するなど、問題は何ですか？

Answer 19

ROM / FLASHはどれくらいありますか？

4kBのRAMは、実際のコードと静的データを保存するために数百キロバイトのフラッシュがあることを意味します。このサイズのRAMは変数のみを対象とする傾向があり、それらに注意すれば、コード行の点でかなり大きなプログラムをメモリに収めることができます。

ただし、C ++では、オブジェクトの実行時の構築規則により、コードやデータをFLASHに格納するのが難しくなる傾向があります。 Cでは、定数構造体を簡単にフラッシュメモリに配置し、ハードウェア定数オブジェクトとしてアクセスできます。 C ++では、定数オブジェクトはコンパイラがコンパイル時にコンストラクタを評価することを要求しますが、これはまだC ++コンパイラができることを超えていると思います（理論的にはあなたはそれを行うことができますが、実際には非常に難しいです） 。

つまり、「小さなRAM」、「大きなフラッシュ」でどんな環境でも私はいつでもCと一緒に行きます。非クラスベースコード用の優れたC ++機能のほとんどを備えたC99の中間選択として適切であることに注意してください。

Answer 20

一般的にはありません。 C ++はCのスーパーセットです。これは、特に新しいプロジェクトに当てはまります。

CPU時間とメモリフットプリントの点で高価になる可能性のあるC ++コンストラクトを避けることで、あなたは正しい軌道に乗っています。

多型のようなものは非常に価値があることに注意してください-これらは本質的に関数ポインタです。必要な場合は、賢く使用してください。

また、優れた（適切に設計された）例外処理により、組み込みアプリは、従来のエラーコードで処理するアプリよりも信頼性が高くなります。

Answer 21

C IMHOを好む唯一の理由は、プラットフォームのC ++コンパイラが正常な状態でない場合（バグが多い、最適化が不十分など）です。

Answer 22

C ++ for Game Programmers には、コードサイズに関する情報が記載されています。 C ++の機能に基づいて増加します。

Answer 23

C99にはインラインがあります。たぶん、あなたは俳優が好きですが、dtorsを正しくするビジネスは面倒です。 Cを使用しない残りの唯一の理由が名前空間である場合、私は本当にC89に固執します。これは、わずかに異なる組み込みプラットフォームに移植したい場合があるためです。その後、同じコードでC ++で記述を開始できます。ただし、C ++はCのスーパーセットではありません。次のことに注意してください。 / p>

sizeof 'a' ＆gt; C ++ではなく、Cで1。 Cには、VLA可変長配列があります。例： func（int i）{int a [i] 。 Cには、VAM変数配列メンバーがあります。例： struct {int b; int m [];} 。

Answer 24

「UNLIMITED」のシステムはないことを伝えたいだけです。リソース。この世界のすべては制限されており、すべてのアプリケーションは、ASM、C、JAVA、またはJavaScriptに関係なく、リソースの使用を考慮する必要があります。いくつかのMbsを割り当てるダミー（「念のため」） iPhone 7、Pixel、およびその他のデバイスの動きが非常に遅くなります。 4 KBまたは40 Gbのどちらでも構いません。

しかし、リソースの浪費に反対する別の側面から-それらのリソースを節約するのにかかる時間です。すでに実装、テスト、および配布されているC ++を使用する代わりに、Cで簡単なことを書いて数ティックと数バイトを節約するのに1週間余分にかかる場合。なぜわざわざ？ USBハブを購入するようなものです。はい、あなたは自分でそれを作ることができますが、それは良くなるでしょうか？より信頼できる？時間をカウントすると安くなりますか？

ちょっと考えてみてください-コンセントからの電力も無制限ではありません。それがどこから来たのかを調べてみてください。何かを燃やしているのがほとんどです。エネルギーと物質の法則はまだ有効です。物質もエネルギーも現れたり消えたりするのではなく、変化するのです。

Answer 25

メモリ割り当ての問題については、Quantum Platformとそのステートマシンアプローチを使用することをお勧めします。初期化時に必要なものはすべて割り当てられるからです。また、競合の問題を軽減するのにも役立ちます。

この製品は、CとC ++の両方で実行されます。

Answer 26

コンパイラに依存します。

すべての組み込みコンパイラーがすべてのC ++を実装しているわけではありません。実装されていても、コードの膨張を回避するのは得策ではありません（テンプレートでは常にリスクです）。いくつかの小さなプログラムでテストし、問題が発生するかどうかを確認します。

しかし、優れたコンパイラを考えると、いいえ、C ++を使用しない理由はありません。

Answer 27

組み込み開発にISO C ++を使用する方法の例を見つけました。これは、C ++またはCを使用するたびに決定を下す人にとって興味深いものです。

Bjarne Stroustrup 彼のホームページで提供されました：

ISO C ++を本格的な組み込みシステムプログラミングに使用する方法については、 JSF航空機C ++コーディング標準。

Answer 28

質問の異なる側面に対する異なる回答の投稿：

＆quot; malloc＆quot;

以前の回答のいくつかは、これについてかなり話します。なぜあなたはコールが存在するとさえ思いますか？本当に小さなプラットフォームの場合、mallocは利用できないか、または間違いなくオプションになる傾向があります。動的なメモリ割り当ての実装は、システムの下部にRTOSを配置する場合に意味がありますが、それまでは純粋に危険です。

それなしでは、非常に遠くまで到達できます。ローカル変数用の適切なスタックさえ持っていないすべての古いFORTRANプログラムについて考えてみてください...

Answer 29

世界中にはさまざまなコントローラーメーカーが存在し、それらの設計と構成に使用する必要がある命令セットを確認すると、多くの問題が発生する可能性があります。アセンブリ言語の主な欠点は、マシン/アーキテクチャに依存することです。開発者がさまざまなコントローラーのコーディングを達成するためにそこに設定されているすべての指示を心からお願いすることは、本当に大きな要請です。 Cは、ハードウェア依存の詳細からアルゴリズムとデータ構造を抽象化するのに十分な高レベルであり、ソースコードをさまざまなターゲットハードウェア、アーキテクチャに依存しない言語で移植でき、コードを変換して保守します。ただし、C、C ++、Python、Javaなどの一部の高レベル言語（オブジェクト指向）は、組み込みシステム開発の監視下に置くのに十分なほど進化していることがわかります。

Answer 30

このような制限されたシステム。アセンブラーに行くだけです。あらゆる側面を完全に制御し、オーバーヘッドを与えません。

多くの組み込みコンパイラは最適なオプティマイザーではないため、おそらくはるかに高速です（特に、デスクトップ用（Intel、Visual Studioなど）のような最先端のコンパイラと比較した場合）

＆quot;えええええ...しかし、cは再利用可能です...」このような制限されたシステムでは、とにかく別のシステムでそのコードの多くを再利用しない可能性があります。同じシステムで、アセンブラは再利用可能です。