16

C ++の想定される精神は、「使用するもの、支払うもの」です。ただし、これは、STLでの例外とその普及により、非常に衰弱させる可能性があります。

誰かが「例外をオンにするだけ」と言う前に、私たちが住まなければならないプログラミング環境では人生はそれほど寛大ではありません。私のものは、実行環境がスタックをほどくのに十分なC++ランタイムを提供しないカーネルプログラミングです。

STLコンテナは、基盤となるバッキングストアにストレージを再割り当てできない場合、割り当て失敗の例外をスローします。環境で例外が有効になっていない場合、プログラムはかなり不思議なことにクラッシュします。実装がまっすぐに中止されるのを見たことがあるか、割り当てが機能しなかったとしても機能すると想定しています。

私が遭遇した多くのCADTライブラリは、エラーコードを返すか、出力パラメータとしてエラーを使用することで、この問題に事前に対処しています。

この問題に対処するための「最良の」C++の方法は何ですか？

明確にするために

標準ライブラリは使いたくない、使えない。私は「できないことをどうやってやるのか」とは問いません。私は尋ねています：「きれいな状態で、コンテナライブラリをどのように構築する必要がありますか？」

4

2 に答える 2

18

それは簡単です。すべてに標準ライブラリを使用する必要があるとは思わないでください。

標準ライブラリは、機能を利用するためのデフォルトの場所となることを目的としています。しかし、それはすべての状況で適切であるという意味ではありません。たとえば、カーネルプログラミングなど。これはかなりニッチな環境であり、C++プログラマーの大多数が気にしないことを直接かつ明示的に制御する必要があります。

特にコンテナからの内部メモリ割り当てのようなものの失敗を通知するためのC++標準メカニズムは、例外をスローすることです。大多数のアプリケーションは、わざわざその例外をキャッチすることはありません。万が一、メモリが不足した場合、彼らはただ死にます。それは彼らにとっては問題ありません。これらの場合にエラーコードを返すことは、せいぜい困難です（std::vector<std::string>内部std::stringの1つがOOMを取得するものである場合はどうなりますか？エラーコードを取得するのは誰ですか？コンストラクタの失敗をどのように通知しますか？例外はstd::stringsコピーコンストラクタによってスローされますか？）。そして、本当に気にかける必要がある人だけがそれを捕まえるのに十分気になります。

制限された環境、つまり標準ライブラリが処理するように設計されていない環境で作業しています。だから...その環境では使用しないでください。

私の提案は、EASTLのコピーを追跡することです。それは本当にこの種のもののために設計されています。リンクしたGithubリポジトリには、いくつかのバグ修正などがありますが、それでもほとんど同じです。それは悪いコードではありません。それらのSTLのようなコンテナーは、ほとんどのインターフェースを提供するため、ほとんどの場合、ドロップインの代替品になります。ただし、メモリ割り当てを具体的に制御するための特別な機能を提供します。そして、彼らは投げません（または、少なくとも、あなたは投げをオフにすることができます）。

于 2012-03-25T04:35:49.250 に答える
3

問題は本当にあなたの環境にあるようです。スタックの巻き戻しはそれほど複雑ではありません。いくつかの制限を設けたい理由はわかります.10MBのオブジェクトをスローすることは合法的なC++です.しかし、カーネルモードでも、std::bad_alloc非仮想呼び出しによるスローをサポートできるはずです.

それを念頭に置いて、STL 設計は完全に正気です。インターフェイスは最小限の例外サポートのみを必要とし、実装は環境に合わせて調整できます。

于 2012-03-26T10:01:00.250 に答える