boost::multi_array コンストラクターまたはサイズ変更メソッドが bad_alloc 例外 (または、割り当てまたはサイズ変更が失敗したことを示す他の例外) をスローできるかどうかを調べようとしています。この情報はドキュメントのどこにも見つかりません。
明確化（コメントから追加）：
これは、割り当てが失敗した場合に、メモリの消費量が少ない (低速な) メソッドにフォールバックできる科学的アルゴリズムです。基本的に、クエリ内の遺伝子のすべてのペアと、多数のデータセットのそれぞれの相互検証セット内のすべての遺伝子との間の「距離」(相関) を保持するために、2 つの動的に割り当てられた 3 次元配列があります。より遅い方法では、必要に応じてその場で各距離を再計算します。これは、両方のメソッドを実装し、メモリ不足の例外にフォールバックする既存の Java 実装の C++ バージョン用です。私は実際にメモリが不足するとは思っていません。
1番目：（実際の質問に答える）：動的に割り当てられたメモリを使用するため、はい、スローできますstd::bad_alloc（ブースト変換の例外を見std::bad_allocたことがありません。そうするのはおかしいでしょう）。
2番目:(明確化に関するコメント):実行時にアルゴリズムのパフォーマンスを最適化するには、利用可能な物理メモリの情報が必要です。std::bad_allocただし、最新のオペレーティング システムはovercommitなどを使用しているため、利用可能なメモリ量を判断するために頼ることはできません。実際にアクセスしようとした場合にのみ、存在することに失敗します。
Java では、VM が多くのことを行っているため、これは機能する可能性があります。VM は、いくつかの継続的なメモリ チャンクを割り当てようとし、利用可能な物理メモリと利用可能な未使用の物理メモリに関して、GC にさらに負荷をかけるかどうかを決定します。または、より大きなジャンクを割り当てるだけです。また、パフォーマンス上の理由から、仮想メモリと物理メモリはまったく異なる概念であることを考慮する必要があります。
そのような場合にアルゴリズムのパフォーマンスを最適化する必要がある場合 (仕事の分野によっては必要になる場合もあります)、「現実世界」がどのように見えるかを教えてくれるプラットフォーム固有の関数を検査する必要があります。
テストしてみませんか？途方もなく高い値を渡して例外を生成するのは簡単です。
一方、この例外が発生した場合はどうする予定ですか? std::bad_alloc通常、ミクロレベルでは対処できない種類の例外です...
たとえば、Web サーバーでは通常、何らかのクリーンアップ (db トランザクションのロールバック?) を実行500してから、ユーザーにエラーを返します。
しかし、メモリが使い果たされると、安全にできることはあまりありません。近いことがわかっているメモリの壁にもう一度ぶつかりたくない場合は、慎重に踏む必要があるためです:)
明示的な例外指定がないのは意図的なものです。説明については、このサブセクションを参照してください。さらに、明示的な指定がないということは、関数がスローできる例外のタイプに制限がないことを意味することに注意してください。そのため、少なくとも ctor と resize 関数は、メモリが使い果たされた場合やアイテム オブジェクトのコピーが失敗した場合に例外をスローできます。
Boost に影響を与えた、興味のある一般的なリファレンスは次のとおりです。