5
なぜ私は次のステートメントがstd::string s与えられていないことに気づいた。なぜstd :: string :: max_size（）== std :: string :: allocator :: max_size（）
s.max_size() == s.get_allocator().max_size();
私は、これは面白い、デフォルトstd::stringでsize_type(-1)の理論的限界があるstd::allocator<char>使用する見つける（はい私は、私は2の補数を仮定している知っているが、それは、実際の質問には無関係です）。私は実際的な制限がこれよりもはるかに少ないことを知っています。典型的な32ビットx86システムでは、カーネルは2GB（おそらく1GB）のアドレス空間を占有し、実際の上限はずっと小さくなります。
とにかく、GNU libstdC++のstd::basic_string<>::max_size()は、使用しているアロケータの内容にかかわらず同じ値を返すようです（1073741820など）。
質問が残っているので、なぜstd::basic_string<>::max_size()はget_allocator().max_size()を返しますか？これが仮説上の上限だと私には思われます。割り当てが不足すると、std::bad_allocが投げられますので、試してみてはいかがですか？
これは他の何よりも好奇心が強いです。なぜこの2つの実装が少なくともこの1つの実装では別々に定義されているのか不思議でした。
「そして、もし割り当てが短くなる、それはちょうどstd :: bad_allocを投げるので、なぜ試してみませんか？ "私はあなたのためにそれに答えることができます。大規模な文字列を処理し、大きな文字列に分割する必要があるかもしれません。実際にmax_sizeが何を報告しているかに依存できない場合は、アドホックな制限に頼らざるを得ません。 – GManNickG
私はあなたの意見を見ますが、私は同意しません。現実には、文字列サイズ<= 'max_size（）'は、外部変数（ヒープでどれくらいの量が利用可能か）に依存しているため、失敗する可能性があると仮定する必要があります。 –
合意。私の唯一のポイントは、少なくとも正確なものにしようとするべきです。実用的な数字に最高の希望を与えてください。 :)しかし、難しい質問。 – GManNickG