STLコンテナを学習（および実験）しているときに、システム（gccバージョン4.7.2、x86_64）でベクトルmax_size = 4611686018427387903およびdeque max_size = 2305843009213693951であることがわかりました。私の（限られた）理解から、dequesは通常、ベクトルのリスト（またはベクトルのベクトル？）として内部的に実装されます。その場合、deque の max_size が vector の max_size よりも小さいのはなぜですか? which(vector) は実際にメモリの連続したブロックを必要とし、deque は複数の連続したブロックで動作できる可能性があります。システム構成、現在の状態に関係がありますか、それともあるべき姿ですか?
質問する
214 次
2 に答える
1
あなたの質問には 1 つの詳細が欠けています: どのタイプで max_sizes をテストしましたか? Ideone の gcc 4.7.2 (32 ビット) は、同じ要素タイプが与えられた場合、両方が同じ max_size を持っていると言います。int itsの場合2^30-1- これは、そのシステム上で格納されるデータの最大サイズが(2^32 - 4)バイトであることを意味sizeof(int) == 4します。
これは勝手な推測です: と を比較vector<T>::max_sizeしdeque<U>::max_sizeたことがsizeof(T) == 4ありsizeof(U) == 8ますか? それは近似係数 2 を説明します。
とはいえ、あなたの実験では、2^62-1int をメモリに入れることができないため、max_size は非常に理論的な数値しか返さないことが示されています。-1 は、「最初の」4 バイトを空のままにする必要があるという事実に由来します&vec[0] == NULL。ベクトルに格納されている int 以外のデータをそのプログラムに含めることはできません。これにはベクトル自体が含まれます。
于 2013-02-25T08:27:49.933 に答える
0
お気づきかもしれませんが、4611686018427387903 は2^62 - 12305843009213693951 であり2^61 - 1、これらの数字がどこから来たのかを示すヒントになります (ヒント: システム構成とは関係ありません)。
本当の理由はわかりませんが、これは非常に学術的なものであり、vector や deques の実装方法とは何の関係もないと思います。おそらく、GCC の deque は余分なビットを使用して何か他のものを追跡します。GCC に精通している人なら、おそらくここに参加できます。とにかく、言語標準は何をmax_sizeすべきかについて何も述べていないので、完全にライブラリ/コンパイラの実装者次第です。
これらの数は非常に多く、実際には、近づく前に他のものが爆発するのを見るでしょうmax_size。が非常に小さい奇抜な STL 実装があるかもしれmax_sizeませんが、少なくとも GCC については心配する必要はありません。
于 2013-02-25T06:11:21.077 に答える