この設計の大きな問題の 1 つはint
、スタック上の 100 万の s がおそらくスタックを吹き飛ばすことです。おそらく必要なのは、データ セグメント、またはバイナリ ファイルに保存され、実行時にロードできるある種のリソースにデータを配置することです。データの複数のコピーが必要な場合は、std::vector
実行時に複製して、データがフリー ストア (ヒープ) にあることを確認します。不必要な偶発的な重複の可能性を減らすために (または参照の重複の可能性を減らすために) a shared_ptr
to aを使用することさえあるかもしれません。std::array
unique_ptr
私が言っているのは、4MB のデータではうまく再生できないということだけです。また、他の変数への 4MB 配列の参照の局所性は、最大の関心事ではありません。
コンパイルされたターゲット プラットフォームとフレームワークによっては、この種のデータをバイナリ リソースに詰め込む方法があります。私はマルチメガ ファイルに対して行ったことはありませんが、リソース ファイルに関するビジュアル スタジオのヘルプは次のとおりです。 aspx
「コード内のデータ」は、ロードを根本的に高速化するわけではないことに注意してください(ファイルシステムを1回トラバースして見つけることを除いて)。OS は依然としてバイナリをロードする必要があり、バイナリが大きいほどロードに時間がかかり、値の大きな配列は、個別のファイルと同じようにバイナリで多くのスペースを占有します。本当の利点は、それが実行可能ファイルに対して「誤って配置」される可能性があるファイルではないことですが、リソース フォーク/リソース ファイル/etc メソッドはそれを処理できます。
以下のコメントにあるように、static const
データ (およびグローバル データ) は、ヒープ (別名フリー ストア) とスタック (別名自動ストア) の両方とは異なるデータ セグメントにロードされる傾向があります。標準がそれを何と呼んでいるのか忘れました。関数内のローカル変数は、初期化順序に関して、またはグローバル非ローカル変数とはstatic
異なる動作をすることを知っています (グローバル (またはそうでない) データは、開始前に完全に初期化されますが、ローカルは関数が初めて初期化されるときに初期化されます)。私の記憶が正しければ呼び出されます)。static
static
main
static