c++ - 組み込み開発に C++ の代わりに C を使用する理由はありますか?

Question

質問

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

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

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

非常に限られたハードウェア (4kb の RAM) 向けに開発する場合、C89 を使い続ける理由はありますか?

結論

あなたの答えをありがとう、彼らは本当に役に立ちました！

主な理由は次のとおりです。

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

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

score 72 · Accepted Answer

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

Embedded C++ ワーキンググループは、言語の標準サブセットと、それに対応する標準ライブラリの標準サブセットを提案しました。残念ながら、C User's Journal がなくなったとき、私はその努力を忘れてしまいました。ウィキペディアに記事があり、委員会はまだ存在しているようです。

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

インライン化された関数は、最初から真の関数である必要があるほど十分に大きくない限り、大きな問題を引き起こすことはありません。もちろん、置き換えたマクロにも同じ問題がありました。

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

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

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

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

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

score 54 · Accepted Answer

C ++よりもCを使用する2つの理由：

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

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

確かに、コードストレージスペースの量は覚えておくべきことですが、新しい、より容量の大きいプロセッサが市場に出回っているので、最もコストに敏感なプロジェクトを除いて、以前よりも問題は少なくなります。

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

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

score 27 · Accepted Answer

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

score 21 · Accepted Answer

The Technical Report on C++ Performanceは、この種の優れたガイドです。組み込みプログラミングに関するセクションがあることに注意してください。

また、回答で組み込み C++ について言及されている ++。標準は私の好みに 100% 合っているわけではありませんが、C++ のどの部分を削除するかを決定する際の参考にはなります。

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

ただし、友人はリンカーマップです。頻繁に確認すると、コードのソースや静的メモリの膨張がすぐにわかります。

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

score 17 · Accepted Answer

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

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

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

score 15 · Accepted Answer

ファームウェア/組み込みシステムエンジニアとして、C が依然として C++ よりも優れた選択肢である理由のいくつかを説明できます。もちろん、私は両方に堪能です。

1) 私たちが開発するターゲットの中には、コードとデータの両方に 64kB の RAM を備えているものがあるため、すべてのバイト数を確認する必要があります。はい、コードの最適化を行って 4 バイトを節約しました。これには 2 時間かかりました。 2008年。

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

3) オーバーレイという用語を聞いたことがありますか? コードスペースが非常に少ないため、別のコードセットと交換する必要がある場合があります。ライブラリ関数を呼び出す場合、ライブラリ関数は常駐している必要があります。オーバーレイ関数でのみ使用すると、あまりにも多くのオブジェクト指向メソッドに依存して多くのスペースを浪費しています。したがって、C++ はもちろん、C ライブラリ関数が受け入れられると想定しないでください。

4) ハードウェア設計の制限 (つまり、特定の方法で接続された ECC エンジン) またはハードウェアのバグに対処するために、キャスティングと均等なパッキング (アライメントされていないデータ構造がワード境界をまたぐ場合) が必要です。暗黙のうちに多くを想定することはできないのに、なぜオブジェクト指向が多すぎるのでしょうか?

5) 最悪のシナリオ: オブジェクト指向メソッドの一部を削除すると、develop は、爆発する可能性のあるリソースを使用する前に考える必要があり (つまり、データバッファーからではなくスタックに 512 バイトを割り当てる)、潜在的な最悪のシナリオのいくつかを防ぐことができます。テストされていないか、コードパス全体をまとめて排除しています。

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

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

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

-サンディスクのファームウェア担当者。

score 10 · Accepted Answer

私の個人的な好みは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を処理するように設定されていない小さな組み込みの世界に特に当てはまります。したがって、常にasm出力を調べない限り、CとC++は互いに同じくらい悪いというのが私の答えです。お互いに同じくらい良いです。

ヒューゴ

score 10 · Accepted Answer

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

個人的には、C スタイルの C++ (型安全のためにテンプレートを使用) を書くと多くの利点が得られると思いますが、そうしない本当の理由は見当たりません。

score 8 · Accepted Answer

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

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

score 6 · Accepted Answer

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

すでに述べたように（RTTI、vtablesなどなし）、C ++でそれを行うことができますが、Cで同等のことを行う場合と同じように、C++の使用があなたから離れないようにするために多くの時間を費やします。。

score 6 · Accepted Answer

正当な理由であり、場合によっては唯一の理由は、特定の組み込みシステム用の C++ コンパイラがまだ存在しないことです。これは、たとえばMicrochip PICマイクロコントローラの場合です。それらは非常に簡単に作成でき、無料の C コンパイラ (実際には C のわずかな変形) がありますが、C++ コンパイラは見えません。

score 6 · Accepted Answer

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

この傾向に対抗するために、私は C++ よりも C を好みます。なぜなら、コードについて、そしてコードがハードウェアとどのように相互作用しているかをより密接に、つまり容赦なく接近して考える必要があるからです。

長い経験から、C は問題に対するより良い解決策を考え出すことを強制するものだと私は信じています。それは、一部のコンパイラライターが良いアイデアだと考えた制約を満たすために多くの時間を無駄にすることを強制せずに、邪魔にならないようにすることです。、または「カバーの下で」何が起こっているかを把握します。

その意味で、C のような低レベル言語では、ハードウェアと優れたデータ構造/アルゴリズムバンドルの構築に多くの時間を費やす必要がありますが、高レベル言語では、そこで何が起こっているのか頭をかきむしるのに多くの時間を費やします。、および特定のコンテキストと環境で完全に合理的なことを実行できない理由。コンパイラを打ち負かして提出すること (強い型付けは最悪の犯罪者です) は、生産的な時間の使い方ではありません。

私はおそらくプログラマーの型にはまっています - 私はコントロールが好きです。私の見解では、それはプログラマーの性格上の欠陥ではありません。コントロールは、私たちが報酬を得るものです。より具体的には、FLAWLESSLY コントロールです。C は、C++ よりもはるかに多くの制御を提供します。

score 4 · Accepted Answer

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

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

score 3 · Accepted Answer

非常に限られたハードウェア（4kbのRAM）で開発する場合、C89を使い続ける理由はありますか？

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

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

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

IMHO、一般的に、組み込みアプリケーションでは、起こっていることすべてを知りたいです。誰がメモリ/システムリソースを使用していますか、どのくらい、そしてなぜですか？彼らはいつ彼らを解放しますか？

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

score 3 · Accepted Answer

Cは移植性に勝っています-言語仕様のあいまいさが少ないためです。したがって、さまざまなコンパイラなど間ではるかに優れた移植性と柔軟性を提供します（頭痛の種が少なくなります）。

ニーズを満たすためにC++機能を活用しない場合は、Cを使用してください。

score 2 · Accepted Answer

ROM/FLASH はどのくらいありますか?

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

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

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

score 2 · Accepted Answer

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

それも共通点の選択です。ほとんどの優れた C プログラマーは、C++ を問題なく使用できます (ただし、多くの人が C++ を使用していると不満を漏らします) .. しかし、(私の経験では) その逆が真であるとは思いませんでした。

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

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

私の個人的な好みは C です。

コードのすべての行が何をしているか (およびコスト) を知っている
コードのすべての行が何をしているか (およびコスト) を知るほど C++ をよく知らない

はい、私は C++ に慣れていますが、標準の C ほどよくは知りません。

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

score 1 · Accepted Answer

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

CPU 時間とメモリフットプリントの点でコストがかかる可能性のある C++ 構造を回避するという正しい方向に進んでいます。

ポリモーフィズムのようなものは非常に価値があることに注意してください - これらは基本的に関数ポインタです。それらが必要な場合は、賢明に使用してください。

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

score 1 · Accepted Answer

C IMHO を優先する唯一の理由は、プラットフォームの C++ コンパイラが適切でない場合 (バグがある、最適化が不十分など) です。

score 1 · Accepted Answer

C99でインライン化しています。ctor が好きかもしれませんが、dtor を適切に作成する作業は面倒な場合があります。C を使用しない残りの唯一の理由が名前空間である場合、私は本当に C89 に固執します。これは、わずかに異なる組み込みプラットフォームに移植したい場合があるためです。後で同じコードを C++ で書き始めることができます。ただし、C++ が C のスーパーセットではない場合、次の点に注意してください。C89 コンパイラを使用していると言ったのは知っていますが、この C++ の比較を C99 と行っていることは知っています。たとえば、最初の項目は K&R 以降のすべての C に当てはまります。

sizeof 'a' > 1 は C では、C++ ではありません。C では、VLA 可変長配列があります。例: func(int i){int a[i] . C では、VAM 変数配列メンバーがあります。例: struct{int b;int m[];} .

score 1 · Accepted Answer

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

すべての組み込みコンパイラがすべての C++ を実装しているわけではありません。たとえ実装していたとしても、コードの肥大化を回避するのが得意ではない可能性があります (これは常にテンプレートのリスクです)。いくつかの小さなプログラムでテストして、問題が発生するかどうかを確認してください。

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

score 0 · Accepted Answer

質問の別の側面に対する別の回答投稿:

「マロック」

以前の返信のいくつかは、これについてかなり語っています。なぜその呼び出しが存在すると思いますか? 本当に小さなプラットフォームの場合、malloc は利用できないか、完全にオプションである傾向があります。動的メモリ割り当てを実装することは、システムの底部に RTOS がある場合に意味がある傾向がありますが、それまでは純粋に危険です。

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

score -6 · Accepted Answer

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

多くの組み込みコンパイラは最適なオプティマイザではないため、おそらくはるかに高速です (特に、デスクトップ用に使用されている最新のコンパイラ (インテル、ビジュアルスタジオなど) と比較した場合)。

「ええええ...しかし、cは再利用可能で...」. このような限られたシステムでは、別のシステムでそのコードの多くを再利用する可能性はほとんどありません。同じシステムで、アセンブラは再利用可能です。

c++ - 組み込み開発に C++ の代わりに C を使用する理由はありますか?

質問

結論

29 に答える 29

Related

Reference