29

私の知る限り、一般的な OS には他の言語で記述された部分がありますが、カーネルは完全に C で記述されています。

C++ でカーネルを作成することが可能かどうかを知りたいのですが、そうでない場合、欠点は何でしょうか。

4

9 に答える 9

27

C ++で実装された、よく使用されるオペレーティング システム (またはその一部) の例はたくさんあります。次に、eCOS RTOS があります。ここでは、カーネルが C++ で実装され、テンプレートも使用されます。

オペレーティング システムは伝統的に、C で難しい方法で実装された OO 概念の例であふれていますkobject。ダウンキャスト。

Windows NT カーネルには、さらに根深いカーネル オブジェクトの継承階層があります。そして、カーネル コードでの例外処理の適切性について不平を言うすべての傍観者に対して、まさにそのようなメカニズムが提供されます。

従来、カーネル コードで C++ を使用することに対する反対意見は次のとおりでした。

  • 移植性: すべてのターゲット プラットフォームで C++ コンパイラを利用できる。これはもう問題ではありません
  • RTTI や例外などの C++ 言語メカニズムのコスト。それらが使用される場合、明らかに標準の実装は適切ではなく、カーネル固有のバリアントを使用する必要があります。これは一般的に EC++ の使用の背後にある原動力です
  • C++ API の堅牢性、特に脆弱な基本クラスの問題

間違いなく、例外とRAIIパラダイムを使用すると、カーネル コードの品質が大幅に向上します。代替手段を確認するには、BSD または Linux のソース コードを確認するだけで済みますgoto。

于 2012-09-12T10:41:32.417 に答える
27

これは、OSDev Wikiで明示的にカバーされています。

基本的に、特定のもの (RTTI、例外など) のランタイム サポートを実装するか、それらの使用を控える (使用する C++ のサブセットのみを残す) 必要があります。

それ以外では、C++ はより複雑な言語であるため、それを台無しにしない、もう少し有能な開発者が必要です。もちろん、Linus Torvalds が C++ を嫌っているのはまったくの偶然です。

于 2012-09-12T09:54:42.787 に答える
14

Torvalds の懸念や他の場所で言及されている他の問題に対処するには: C++ で記述されたハード RT システムでは、STL/RTTI/例外は使用されず、同じプリンシパルをはるかに寛大な Linux カーネルに適用できます。「OOP メモリ モデル」または「ポリモーフィズム オーバーヘッド」に関するその他の懸念は、基本的に、プログラマがアセンブリ レベルまたはメモリ構造で何が起こるかを実際に確認したことがないことを示しています。C++ は効率的であり、最適化されたコンパイラのおかげで、手元に仮想関数がないためにルックアップ テーブルを作成する C プログラマよりも何倍も効率的です。

平均的なプログラマーの手に渡れば、C++ は、C で書かれたコードに対してアセンブリ コードを追加することはありません。ほとんどの C++ コンストラクトとメカニズムの asm 変換を読んだことで、コンパイラには C よりも最適化する余地があり、より無駄のないコードを作成できる場合があると言えます。したがって、パフォーマンスに関しては、C++ で OOP の機能を利用しながら、C++ を C と同じくらい効率的に使用するのは非常に簡単です。

したがって、答えは、事実とは関係なく、基本的に偏見を中心に展開し、CPP が作成するコードを実際には知らないということです。私は個人的にCをC++とほぼ同じくらい楽しんでおり、気にしませんが、オブジェクト指向設計をLinuxの上またはカーネル自体に階層化することに対して合理的な理由はありません。それはLinuxに多くの利益をもたらしたでしょう。

于 2016-01-07T16:02:34.090 に答える
9

OS カーネルは、多かれ少なかれ好きな言語で作成できます。

ただし、C を好む理由がいくつかあります。

  • 簡単な言語です！魔力はほとんどありません。コンパイラがソース コードから生成するマシンコードについては、さほど困難なく推論できます。
  • かなり速い傾向にあります。
  • 必要なランタイムはあまりありません。それを新しいシステムに移植するのに必要な労力は最小限です。
  • 多くの異なる CPU およびシステム アーキテクチャをターゲットとする適切なコンパイラが多数あります。

対照的に、C++ は非常に複雑な言語である可能性があり、ますます高レベルの OOP コードをマシン コードに変換するために非常に多くの魔法が行われます。生成されたマシン コードについて推論するのは難しく、パニック状態のカーネルや不安定なデバイス ドライバーのデバッグを開始する必要がある場合、OOP 抽象化の複雑さが非常に苛立たしくなり始めます...特に、ユーザーフレンドリーでない方法でそれを行う必要がある場合ポートをターゲット システムにデバッグします。

ちなみに、システム プログラミング言語について強い意見を持つ OS 開発者は Linus だけではありません。OpenBSD の Theo de Raadt も、この件に関していくつかの選択的な引用を行っています。

于 2012-09-12T10:14:14.697 に答える
4

C++ でカーネルを作成する可能性は簡単に確立できます。それは既に行われています。EKA2は、C++ で記述された Symbian OS のカーネルです。

ただし、Symbian 環境では、特定の C++ 機能の使用にいくつかの制限が適用されます。

于 2012-09-12T10:32:22.147 に答える
1

長年の改訂：

振り返ってみると、最大の問題は、実際には C++ の大量の高レベル機能にあると思いますが、それらは隠されているか、プログラマーの制御外にあります。標準では、特定の実装方法を強制するものではありません。ほとんどの実装が一般的な健全性に従っている場合でも、100% 明示的であり、OS カーネルでの実装方法を完全に制御できる多くの正当な理由があります。

これにより、(自分が何をしているのかを知っている限り) メモリ フットプリントを削減し、OOP パラダイムではなくアクセス パターンに基づいてデータ レイアウトを最適化し、キャッシュの使いやすさとパフォーマンスを向上させ、大量のファイルに隠れている可能性のある潜在的なバグを回避できます。 C++ の高度な機能。

はるかに単純であっても、場合によっては C でさえ予測できない場合があることに注意してください。これが、カーネル コードにプラットフォーム固有のアセンブリが多数存在する理由の 1 つです。

于 2012-09-12T10:00:27.477 に答える
-6

C の大きな利点の 1 つは、読みやすさです。より読みやすいコードがたくさんある場合:

foo.do_something();

また：

my_class_do_something(&foo);

C バージョンでは、foo が使用されるたびに、foo の型が明示されています。C++ では、舞台裏で非常に多くのあいまいな「魔法」が行われています。そのため、コードの小さな断片を見ているだけでは、可読性が大幅に低下します。

于 2014-12-27T00:07:26.603 に答える