enh: ハッシュテーブルのclearメソッドの備考追加

[math-hiyoko]

概要

close #1449

std:: unordered_setやstd:: unordered_mapをはじめとするハッシュテーブルのclearメソッドについて、その規格が定義する「計算量」（オブジェクトに対する操作の数）は本関数呼び出し前のコンテナの要素数に比例するものとされている。
しかし、GCC libstdc++, LLVM libc++ などの多くの実装では実行時間は概ね bucket_count() + size() に比例する。
#1449 (comment)

また、このメソッドはバケットのために確保された動的メモリを解放することを保障していない。

gccの実装: https://github.com/gcc-mirror/gcc/blob/fd50d2a24adaff9a9ba749fd0a1eb5a5c5ee35a8/libstdc%2B%2B-v3/include/bits/hashtable.h#L2707-L2720
clang LLVMの実装: https://github.com/llvm/llvm-project/blob/ad060dfa4c910e8253ba328be947ef70f6597326/libcxx/include/__hash_table#L1338-L1348

これを受けて、該当するメソッドの計算量に関する記述に備考を追加したものである

[github-actions]

⚡ プレビュー (HTML) (更新時刻: 2025-05-30 02:07:40 JST)

• ⫯ Commit: 5079252
• プレビューの生成には時間がかかります (3～5分)。進捗状況はこちらをご確認ください。

変更記事一覧

• 📝 reference/unordered_map/unordered_map/clear
• 📝 reference/unordered_map/unordered_multimap/clear
• 📝 reference/unordered_set/unordered_multiset/clear
• 📝 reference/unordered_set/unordered_set/clear

※ソース (.md) に直接変更のあった記事を列挙しています。グローバル修飾や変換規則の変更による変化は考慮していません。

[akinomyoga]

あとこれは今回の PR に留まる話ではないですが、計算量が〇〇に比例するという表現は、ちょっと違和感があるかもです。改めて自身に問うてみると以下の2点がある気がします。

• 計算量 (complexity) 自体がコンテナサイズが大きくなる極限で"どのような関数と比例するか"という概念もしくは"アルゴリズムのクラス"なので、それが〇〇と比例するというのは変な気がする。
• また、比例というと厳密に比例していそうな気がしてしまいますが、計算量が線形というのは実際には極限において計算時間が線形の関数で上から抑えられるという意味なので、単純に比例と言い換えられるのか疑問。

[faithandbrave]

ぼくも比例という言い方には違和感がありますが、いい表現が思いつかないところではあります。

[math-hiyoko]

計算量が〇〇に比例するという表現は、ちょっと違和感があるかもです
ぼくも比例という言い方には違和感がありますが、いい表現が思いつかないところではあります。

計算量はバケット数をcとしてO(c)となる
計算量はバケット数cに対してO(c)となる

と言ったところでしょうか？少なくとも #1450 (comment) で述べられている問題点はクリアできていそうな気がします。

[akinomyoga]

個人的には、規格には linear って書いてあるのだから素直に「線形」で良い気がしています:

計算量は〇〇に対して線形となる。

これが規格に一番忠実です。或いは線形というのは cpprefjp 読者に対して分かりにくいという配慮でしょうか。

[math-hiyoko]

個人的には、規格には linear って書いてあるのだから素直に「線形」で良い気がしています:

良いと思います。
この場合、
「時間計算量はバケット数と全要素数の和に対して線形となる。」
という表現は許容されるでしょうか？
#1450 (comment) だからこれは気にしなくて良いですね

[math-hiyoko]

一旦ご指摘いただいた内容は全て反映しました
ご確認ください

[math-hiyoko]

コメントいただいたものは全て反映しました

[yumetodo]

だいぶ煮詰まって固まってきた気配がするので読んでみました。

swap技法の紹介の部分ですが、これってvectorだと一見して非自明なのでshrink_to_fitが導入され、それでで行うべしとなったものですよね。

unordered_map/setコンテナについてswapによって同種のことが達成できるというのは、現状の備考のように記載いただいてもなお自明に理解できるものではない気がしており、
余力があればでいいのですが、その根拠を注釈として追加することを検討していただけないでしょうか？
(そこまでのモチベーションはないということでしたら無視していただいて構いません)

[math-hiyoko]

少し話が逸れてしまう気もするのですが、

• メモリを確実に解放したいときには以下のように操作を行う

std::unordered_multiset<int> tmp;
s.swap(tmp);

とありますが、これだとtmpがスコープ抜けるまではメモリ解放されませんよね

その観点で

s = std::unordered_multiset<int>();

の方が良い気がするし、現状記載されているswapによるやり方が「なお自明に理解できるものではない」問題も解消できると思いました

[math-hiyoko]

s = decltype(s)();

の方が綺麗かも

[Raclamusi]

s = decltype(s)(); は以下のような状況で使えないので、swap技法から変えるなら s = std::unordered_set<int>(); の方がいいと思います。

void f(std::unordered_set<int>& s) {
    s = std::unordered_set<int>();  // ok
    //s = decltype(s)();  // error!
}

[faithandbrave]

decltypeは併記して紹介してもいいとは思いますが、リファレンスサイトなので明確であった方が読者に伝わりやすいという点でも、型は書いておくと安心感がありそうではあります。

それとすいません。unordered_mapのデフォルトコンストラクタの仕様を確認したところ、以下のように書いてありました。

バケット数の最低が実装依存の、要素を持たない空の unordered_map を構築する。
https://cpprefjp.github.io/reference/unordered_map/unordered_map/op_constructor.html

バケット列が完全に空というわけではないので、その点補足が必要そうです。。。

[faithandbrave]

「バケット数を初期状態まで縮小させたい場合は、」みたいな感じでしょうか…

[math-hiyoko]

「バケット数を初期状態まで縮小させたいときは、」と書き直し、
swapを使うやり方から新しいインスタンスを代入するやり方に修正しました

[faithandbrave]

忍耐強く対応していただいてありがとうございます。
私としては必要十分な内容になったと思いますので、あとは @akinomyoga さんのコメントに最後対応していただけたらマージできると思います。

[math-hiyoko]

いただいたご指摘には全て対応しました
みなさん様々な観点から丁寧なコメントをくださってありがとうございました

[faithandbrave]

マージしましたー。

@math-hiyoko
大変な作業だったと思いますが、対応ありがとうございました。
読者への有用な情報の提供もありがとうございます。
@math-hiyoko さんを編集チームに招待させていただきますね。のちほどGitHubから招待の通知が届くと思います。もしよろしければ今後ともよろしくお願いします。