std::mapには、ヒントが正しい場合にlog（n）から一定時間までの挿入時間を短縮する「ヒント」イテレータを使用するinsertメソッドがあります。コンテナは、新しく追加されたアイテムがヒントよりも少なく、ヒントの前のアイテムよりも大きなキーを持っていることを確認できるだけなので、これがどのように機能するかはかなり明白です。それ以外の場合、ヒントが間違っていて、通常の挿入が実行されます。std :: unordered_mapヒント付き挿入
std::unordered_mapもまた、ヒント機能を有するinsertを有する。ヒントは何をしますか？ハッシュマップの挿入を高速化するために、もう1つの「ヒント」イテレータをどのように使用することができるかはわかりません。
これを使用する場合、適切な「ヒント」は何ですか。 std::mapでは、ヒントは通常、マップ上のlower_boundを呼び出すことによって検出されます。
これはインターフェイスの互換性の問題です。基本的には、デザインはstd::mapのインタフェースを考慮して行われます。
言い換えれば、std::unordered_mapの場合、ヒントが提供されるかどうかは異なりません。ここのコメントから
追加情報：
迅速/簡単mapとunordered_map切り替えることが可能であることが、パフォーマンスは、多くの場合では決定的な要因であるため、痛みを伴わずの貴重な柔軟性が移行提供するため、インターフェースの互換性は非常に重要ですもう一方を選ぶ。
+1はい、インターフェースの互換性はジェネリックコードにとって非常に重要です（たとえば、コンテナがテンプレートパラメータの場合、テンプレート
@HowardHinnant：OPが指摘するように、ヒントはmap :: lower_bound（）を呼び出すことによって得られ、unordered_mapにはこのメソッドがありません（順序付けられていないコンテナでは意味がありません）。これはインタフェースの互換性がまだ提供されていないことを意味しませんか？ –
@AndyT：インターフェイスの互換性には明確な制限があります。しかし、 'find'と' equal_range'は、両方のAPIで見つかるイテレータの豊富なソースです。前後の切り替えが重要な目標である場合は、共通のAPIサブセットに固執する必要があります。委員会は、unordered_mapに挿入するときに役に立たないヒントを提供できるように、サブセットを実用的な大きさにするためにできることはすべて行っています。 –
ヒントオーバーロードは、通常の 'std :: map'とのインターフェース互換性のためだと思います。これは、値のハッシュを挿入して何か便利なことをする場所を正確に知る必要があるからです。基本的に 'unordered_map'が内部的に何を再現するのか、負荷、バケットなどを考慮する必要があります。また、あなたが指摘したように、挿入は償却O（1）とにかくです。 – Xeo
明らかにするには、何もしないと言っているのですか？それは私が推測していたものです。それは互換性のためだけのものでした。 – pauld