オペレーティングシステムがCおよびC ++で低レベルの処理を行うのはなぜですか？なぜC ++だけではないのですか？

WindowsのWikipediaページには、Windowsがブートローダーとタスクスイッチャー用にAssemblyで、カーネルルーチン用にC と C ++で記述されていることが記載されています。

IIRC、あなたがからC ++の関数を呼び出すことができるextern "C"「Dブロック。カーネル関数にCを使用して、純粋なCアプリがそれらを使用できるようにすることができます（printfなど）が、それらをextern "C "ブロックにラップすることができるのであれば、なぜCでコードを書くのですか？

これは主に歴史的な理由によるものです。Windowsカーネルの一部はもともとCで書かれていました。これは、1983年、30年以上前にWindows 1.0がリリースされたときにC ++がほとんどリリースされなかったためです。これは、Microsoftが下位互換性をセールスポイントにし、C ++のCパーツのバグ互換バージョンを書き換えるのに効果的なメリットがないために多大な労力を必要とするためです。

ほとんどの人が指摘しているように、理由ははるかに歴史的ですが、誰も言及していないものがあり、それが人々が低レベルのCコードを書く理由だと思います。

Cは、仕様が（比較的）短いという意味で小さな言語です。C ++は巨大であり、控えめな表現です。これはプログラマにとってはそれほど重要ではないかもしれませんが（そうは思いますが）、正式な検証を行いたい場合には非常に重要です。さらに、Cコード分析用の確立されたツールがあり、バグなどの防止に役立ちます。

また、これは、他の業界に比べて展開されるバグのコストが非常に高い組み込みソフトウェアでは非常に重要です（Webを比較すると、すべてのユーザーにパッチをすぐに適用できます）。ミッションクリティカルなソフトウェアや医療製品は言うまでもありません。

BitCのように、これでさらに優れた言語を使用して、低レベルプログラミングでCを支配的な場所から置き換える試みがありましたが、これまでのところ成功していません。

1. Cランタイムははるかに小さいです。
2. C ++から低レベルの構成体への変換は、Cよりも透過性が低くなります（2つの簡単な例については、参照とvtablesを参照してください）。
3. Cには通常、安定したABIがあります。C ++は通常そうではありません。つまり、最低限、システムコールインターフェイスはCスタイルにする必要があります。さらに、何らかの動的モジュールが必要な場合は、一貫したABIがあれば非常に役立ちます。

理由は技術的なものではありません。アセンブリの少しは不可避であるが、それらはされていない強制的に、彼らは時折Cを使用したいと。私の会社は、ほぼ完全にC ++で記述された独自の独自のカーネルを使用していますが、埋め込みカーネルはC ++アプリケーションでモノリシックにコンパイルされているため、他のほとんどの人のようにカーネルへのCインターフェイスをサポートする必要はありません。あなたはCインタフェースを持っている場合は、それはそれはだにもかかわらず、Cのインターフェイスのコードを記述する方が簡単だ可能使用するextern "C"C ++でそれを書くこと。

サードパーティのコードが主な原因で、Cファイルのごく一部しかありません。サードパーティの低レベルコードはほとんどの場合Cで提供されます。CコードをC ++アプリに組み込む方が他の方法よりはるかに簡単だからです。

多くの場合、カーネル開発者は、ソースからすぐにコードが実際に何をするのかが明らかになったとき、より幸せに感じる種類の人々です。

C ++にはさらに多くの機能があり、単純なCコードが隠すよりもコードが行うことを隠します：オーバーロード、仮想メソッド、テンプレート、参照、スロー...それを使用するコード。

C ++の力は、ライブラリとフレームワークを作成する非常に強力なツールであり、アプリケーション開発を簡単にするものだと思います。C ++アプリケーション開発者は、そのライブラリを使用してアプリケーションを作成する能力が非常に高い場合でも、ライブラリのテンプレートで満たされた内部で完全に失われます。C ++ライブラリの権利を書くことは非常に難しいプログラミングタスクであり、アプリケーション開発者の利益のために優れたフレームワークを提供するためにのみ行われます。C ++ライブラリは、内部的に単純ではありません。アプリケーションプログラマーの観点から見ると、強力でありながら単純です。

ただし、カーネルAPIはC ++ APIにすることはできません。言語に依存しないAPIである必要があるため、C ++の優れた機能のほとんどは、そのインターフェイスで直接使用できません。さらに、カーネルは独立して開発された「ライブラリ」部分と「アプリケーション」部分に実際には分割されず、論理的に1つのライブラリに移動して、大量のアプリケーションの作成を容易にします。

また、カーネル内ではセキュリティと安定性がより重要であり、仮想メソッドは、プレーンコールバックや他のCのようなメカニズムよりもはるかに動的であるため、分離と検証がはるかに困難です。

要するに、もちろんC ++としてのカーネルを含むCプログラムを書くことはできますが、C ++の力のほとんどはカーネルでうまく使用されていません。そして、多くの人は、プログラミングツールは、あなたがすべきでないことをするのを防ぐべきだと主張するでしょう。C ++はそうしません。

Bjarne Stroustrup、1999年7月のインタビュー：

これらの言語はいずれも、他の現代の言語と根本的に異なるものや劇的に優れたものはありませんでした。しかし、彼らは十分であり、運と社会的要因の受益者でした

Cは、その設計上、非常に低レベルの言語です。これは、アセンブラーからわずか1ステップです。対象のチップセットを知っていれば、少し知識があれば、Cを手動でASMに「コンパイル」できます。この種の「金属に近い」言語は、高レベルの最適化（パフォーマンス、メモリ効率など）の鍵となります。ただし、これは金属に近いため、この言語では無料で手に入れることはできません。これは手続き型の非オブジェクト指向言語であるため、このような構成体を使用するには、メモリ内で複数値の構成体を作成および使用するための多くの定型コードが必要です。

C ++は「C one better」であり、動的メモリ割り当て、組み込み構造マーシャリング、定義済みコードの大規模なライブラリなど、いくつかの使いやすさの機能を追加しますが、効率はいくらか低下します（さらにはるかに優れています）管理されたランタイム環境よりも）。平均的なコーダーにとっては、メモリ割り当てなどの肛門保持制御を必要としないコードベースの領域の欠点よりも利点の方がはるかに優れています。

この2つの組み合わせは、かなり伝統的なものです。Cを使用して、コードベースの最もパフォーマンスが重要でメモリ効率の高い領域を記述します。その後、C ++コードからのメソッド呼び出しを介して、より抽象化された方法で作業できます。 、非常に最適化されたCコード。

Cでは、ほとんどの時間を手元の問題とソリューションのコーディング方法について考えることに費やしている可能性があります。C ++では、C ++とその無数の機能、関数、および曖昧な構文について考えることになります。

また、多くのC ++ショップでは、コードが最新のデザインパターンセット、または偉大な神Stroustrupの最新の判読できない文言に夢中になっている「ファッションポリス」によって監視されます。きれいなコードは作業コードよりも価値が高くなります。最新のBoostテンプレートセットの使用を見つけることは、ビジネスに適したソリューションを見つけることよりも賞賛されます。

私の経験では、C ++のすべての巧妙な機能とオブジェクト指向の純度について、プレーンなCでコーディングすることで、より迅速かつ効果的に仕事をすることができます。

Cパーツは、C ++パーツに使用されるC ++コンパイラーにうまく移植できない可能性があります。たぶん、CコードはC ++コンパイラーを破壊する方法でCコンパイラーに乱雑です。

高品質のC ++コンパイラを使用している場合、プロジェクトでCとC ++を混在させる理由はほとんどありません。ほぼ。

1つの理由は、プロジェクトが他のプロジェクトとCコードを共有し、コードがC ++としてコンパイルされず、そのコードのC ++フォークを維持したくないためです。

私はあなたがそれを逆に持っていると思う- extern "C"ブロックはC呼び出し規約がブロック内のすべての関数に使用されることを保証します。したがって、CのC ++関数ではなく、C ++から純粋なC関数を呼び出すことができます。とにかく、人々がCとC ++の両方を使用する理由は、多くの低レベルライブラリがCを使用して記述されており、独自に作成するよりもすでに存在します（おそらくデバッグおよび最適化されます）。OTOH、C ++は、人々が一緒に作業したいと思う多くの素晴らしい高レベルの機能を提供します。

プログラミング言語としてCを使用するさまざまなレベルの組み込みプラットフォームがあります（もちろん、いつでもアセンブリ言語を使用できます）

「レベル」については、システムの内部SRAMおよびROMリソースレベルについて説明しています。

これらのプラットフォームは、リソースに制約がある場合があります（たとえば、一部の8051プラットフォームには128バイトのユーザーSRAMしかありません）。

このように少量のRAMで動的メモリ割り当てをサポートすることは無意味です。（新規/削除）またはCのmalloc

CからC ++への主な改善点の1つは、オブジェクト指向のパラダイムです。C ++は、メモリフットプリントが大きいソフトウェアに適しています

ただし、最大32 KBのサイズ制限がある組み込みファームウェアでは使用できません。（例：16ビットMCUプラットフォーム）

一般にCコンパイラよりも複雑なC ++コンパイラは必要ありません。（少なくともSDKプロバイダーはこれを行うことを気にしません）。

実際、32ビットARM7プラットフォームでC ++コンパイラを見つけることはほとんどできません。

複雑さだけの価値はない

一部の8051（8ビット）：1MB ROM、128B RAM

TI MSP430（16ビット）：32KB ROM、4KB RAM

ST Microelectronics ARM 32ビットCortex™-M3 CPUコア（STM32F103T4）：16または32Kバイトのフラッシュメモリ6または10KバイトのSRAM

考えられる理由はいくつかあります。

• C ++の同等物と比較すると、Cは少し効率的です。
• 彼らが使用するいくつかのライブラリはCで書かれています。
• Cで記述されたLinuxカーネルの一部を使用します。

編集済み：結局のところ、3番目の引数は真ではありません（コメントを参照）。

CはおそらくC ++よりも優れた言語だからです。また、一部のコードはC ++が普及する前に記述されたため、人々はそれを置き換える理由がありませんでした。

また、C ++には、カーネルで使用する際に注意を払わないとコードを壊す可能性のある機能がたくさんあるためです。