[Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change

["atavory at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From atavory at gmail dot com  2005-09-26 22:22 -------
(In reply to comments #2 and #3:
Actually, on second thought, I'm not sure we should give up consistency so easily
only because the it = t.erase(it) idiom cannot be meaningfully used together with
unordered containers: otherwise, why, f.i., vector::erase returns an iterator?!?!)

  For hash-based containers, i = t.erase(i) is effectively similar to:

t.erase(i->first) // or t.erase(*i)
i = t.begin();
std::advance(i, ::rand() % t.size());

(In fact, it's even somewhat worse than the above.) How could the return value
be useful?   

  Conversely, i = t.erase(i) makes sense for both tree-based containers or
vectors, as it can be used in snippets such as the one in the original post.

  The problem is not, IMHO, whether the container is ordered or not (e.g., an
unsorted std::vector). The problem is whether the container's sequence is well
defined. Prior to hash-tables, the STL had only containers with well-defined
sequences. (Put differently, one can think of a vector (or even a list) as an
"associative container" mapping 1 .. t.size() - 1 to the values of t.)

  So, IMHO, this isn't giving up consistency; it's just reflecting inherent
inconsistency through an inconsistent interface.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061