Remove non-Standard <hash_map> and <hash_set>
#5764
Conversation
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
| const _Nodeptr _Bucket_lo = _Vec._Mypair._Myval2._Myfirst[_Bucket << 1]._Ptr; | ||
| for (;;) { | ||
| // Search backwards to maintain sorted [_Bucket_lo, _Bucket_hi] when !_Standard | ||
| // Search backwards for historical reasons |
There was a problem hiding this comment.
I feel a future maintainer/contributor will eventually wonder what's this history. Would love to know the details.
There was a problem hiding this comment.
| // Search backwards for historical reasons | |
| // Search backwards for historical reasons | |
| // Feel free to make it search forward, now that the reasons have disappeared |
There was a problem hiding this comment.
I'm not actually sure if changing the search direction would be an observable behavioral change. git blame will allow future maintainers to perform programmer-archaeology.
There was a problem hiding this comment.
I won't insist, but I do feel that just stating 'for historical reasons' may lead to the conclusion that this behavior must say as-is, which isn't necessary. But as you say - it might not lead to an observable change so perhaps it doesn't matter. Do feel free to merge, it's got my approval :) .
3 participants
Overview
This permanently removes our non-Standard
<hash_map>and<hash_set>headers, which were superseded by C++11<unordered_map>and<unordered_set>.Fixes #5228.
Eliminating this code removes unnecessary complexity from this fiendishly complex library. For users, it removes ways to write non-portable code. For library implementers, it reduces our maintenance burden, making it easier for us to reason about the remaining Standard code.
In July 2015, VS 2015 shipped with impossible-to-ignore "hard deprecations", where we emitted compiler errors telling users that "
<hash_map>is deprecated and will be REMOVED." With 10 years of notice, it's finally time to deliver as promised.Commits
<hash_map>and<hash_set>.stdext::hash_value/hash_compare.<xhash>should avoid including<xstring>#2996, which made<unordered_map>and<unordered_set>avoid including most of<string>. We can retain this escape hatch cheaply, but I believe we should rename it now._LEGACY_CODE_ASSUMES_XHASH_INCLUDES_XSTRINGfollows our usual naming (even though it drags in a bit more). That will avoid confusion (why is a project silencing stdext hash deprecation warnings when stdext hash is gone?) and prompt affected users to take another look and hopefully fix their inclusion assumptions where possible._Standardis always true now.