とても 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() の先頭 遅すぎる。
C++ よりも C を使用する 2 つの理由:
<オール>また、元の質問と多くのコメントで、4 Kb の RAM について言及しています。 .典型的な組み込みプロセッサの場合、コードはフラッシュに格納されて実行されるため、RAM の量は (ほとんど) コード サイズとは無関係です。
確かに、コード ストレージ スペースの量は心に留めておくべきことですが、新しい、より大容量のプロセッサが市場に登場するにつれて、最もコストに敏感なプロジェクトを除いて、以前よりも問題が少なくなります.
組み込みシステムで使用するための C++ のサブセットの使用について:現在、MISRA C++ 標準があり、一見の価値があるかもしれません。
編集: 組み込みシステムの C と C++ に関する議論につながったこの質問も参照してください。
いいえ。問題を引き起こす可能性のある C++ 言語機能 (ランタイム ポリモーフィズム、RTTI など) は、組み込み開発中に回避できます。組み込み C++ 開発者のコミュニティがあり (以前の C/C++ ユーザー ジャーナルで C++ を使用する組み込み開発者によるコラムを読んだことを覚えています)、選択がそれほど悪いものであった場合、彼らが非常に声高になるとは想像できません。