4

OS/カーネルがC++を念頭に置いて作成されており、純粋なCスタイルのものを「実行」せず、代わりに本格的なC++標準ライブラリに基づいて構築されたC標準ライブラリを公開するとします。これは可能ですか?そうでない場合、なぜですか?

PS:Cライブラリが「C ++の一部」であることは知っていますが、内部的にはC++ベースの実装に基づいているとしましょう。

小さな更新:ここでの私のルールによって「許可」されるものについての議論をかき立てたようです。一般的に言えば、C標準ライブラリの実装では、可能な限りC++を使用する必要があります/ Right (tm)。私は主に、アルゴリズムと、舞台裏で静的クラスオブジェクトを操作することについて考えています。私は実際には言語機能を除外しているわけではありませんが、代わりに、適切なC++実装に重点を置いています。setjmpの例に関しては、ここで有効なC(C ++ Cライブラリパーツに事前に実装されている他のライブラリパーツを使用するか、他のライブラリ関数をまったく使用しない)が私の「ルール」に違反する理由はわかりません。C ++ライブラリに対応するものがない場合、なぜそれの使用について議論するのですか。

4

5 に答える 5

4

実際、c ++は、式テンプレートのような多くの変換時間構造をサポートできるため、多くの点でcよりも高速です。このため、c ++マトリックスライブラリはcよりもはるかに最適化される傾向があり、一時的なものや展開ループなどが少なくなります。バリアントテンプレートなどの新しいc ++ 0x機能を使用すると、たとえば、printf関数はより高速でタイプセーフになります。 cで実装されたバージョン。多くのc構造のインターフェースを尊重し、それらの引数(文字列リテラルなど)の変換時間を評価することさえできます。

残念ながら、多くの人はcがc ++よりも速いと考えています。これは、多くの人がOOPを使用して、すべての関係と使用法が大規模な継承階層や仮想ディスパッチなどを通じて発生する必要があることを意味するためです。日々。適切な場所で仮想ディスパッチを使用する場合(たとえば、カーネル内のファイルシステムのように、関数ポインターを介してvtableを構築し、多くの場合、基本的にcでc ++を構築する場合)、cからのペシミゼーションはなく、すべての新機能があります。 、大幅に高速化できます。

速度が向上する可能性があるだけでなく、実装がより良い型安全性から利益を得る場所があります。cには、型の安全性を破り、c ++が強力なエラーチェックを提供できる一般的なトリック(ジェネリックでなければならないときにvoidポインターにデータを格納するなど)があります。タイピングが固定されているため、これは必ずしもインターフェイスを介してcライブラリに変換されるわけではありませんが、ライブラリの実装者にとっては間違いなく役立ち、呼び出しからより多くの情報を抽出できる可能性がある場所で役立つ可能性があります「as-if」インターフェースを提供することによって(たとえば、void *を取るインターフェースは、引数が暗黙的にvoid *に変換可能であることを概念チェックする汎用インターフェースとして実装される場合があります)。

これは、cに対するc++の能力の優れたテストになると思います。

于 2011-08-19T15:57:58.317 に答える
4

はい、それは可能です。これは、C ++、FORTRAN、アセンブラー、またはその他のほとんどの言語で記述されたライブラリからCAPIをエクスポートするのとよく似ています。

于 2011-02-24T19:59:33.833 に答える
1

「純粋なCのもの」はC++と非常に大きな重複があることを考えると、OSカーネルではなく、どのようにすればそれを完全に回避できるかわかりません。結局のところ、+操作は「純粋なCのもの」ですか?:)

そうは言っても、クラスなどを使用して特定のCライブラリ関数を確実に実装できます。std :: sortを使用してqsortを実装しますか?もちろん問題ありません。忘れないでくださいextern "C"

于 2011-02-24T20:12:34.207 に答える
0

Linuxのようなカーネルは、syscall、ioctl、ファイルシステムに基づいており、かなりの数の標準に準拠している非常に厳密なABIを持っています(POSIXが主要な標準です)。ABIは安定している必要があるため、その表面も制限されます。これは多くの作業になりますが(特に、最小限の有用なカーネルも必要になるため)、これらの標準は任意の言語で実装できます。

編集:あなたはlibcについても言及しました。これはカーネルの一部ではなく、前述のABIのおかげで、libcの言語はカーネルの言語とはまったく関係がない可能性があります。カーネルとは異なり、libcはCであるか、Cに対して非常に優れたffiを備えている必要があります。パーツが含まれているC++はextern C問題に適合します。

于 2011-02-24T20:09:39.477 に答える
0

あなたがそれを行うことができなかった理由はわかりませんが、誰かがそのような実装を使用する理由もわかりません。通常の実装よりもはるかに多くのメモリを使用し、少なくともいくらか遅くなります...ただし、stdioの実装がすでに本質的にC ++であるglibcよりもそれほど悪くはないかもしれません...(Lookup GNU libio.. 。あなたは恐ろしいでしょう。)

于 2011-02-24T20:10:27.210 に答える