[Bug libstdc++/70716] Doxygen comments on std containers need updating for C++11 allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70716 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Jonathan Wakely --- Done.
[Bug libstdc++/70716] Doxygen comments on std containers need updating for C++11 allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70716 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Thu Jul 14 10:02:10 2016 New Revision: 238332 URL: https://gcc.gnu.org/viewcvs?rev=238332=gcc=rev Log: Improve doxygen comments for allocators in containers PR libstdc++/70716 * include/bits/forward_list.h (forward_list): Update doxygen comments to reflect allocator propagation semantics. Remove ambiguous statements about data being lost. * include/bits/stl_deque.h (deque): Likewise. * include/bits/stl_list.h (list): Likewise. * include/bits/stl_map.h (map): Likewise. * include/bits/stl_multimap.h (multimap): Likewise. * include/bits/stl_multiset.h (multiset): Likewise. * include/bits/stl_set.h (set): Likewise. * include/bits/stl_vector.h (vector): Likewise. * include/bits/unordered_map.h (unordered_map, unordered_multimap): Likewise. * include/bits/unordered_set.h (unordered_set, unordered_multiset): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/forward_list.h trunk/libstdc++-v3/include/bits/stl_deque.h trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/bits/stl_map.h trunk/libstdc++-v3/include/bits/stl_multimap.h trunk/libstdc++-v3/include/bits/stl_multiset.h trunk/libstdc++-v3/include/bits/stl_set.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/bits/unordered_map.h trunk/libstdc++-v3/include/bits/unordered_set.h
[Bug libstdc++/70716] Doxygen comments on std containers need updating for C++11 allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70716 --- Comment #1 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > Also, assignment operators and functions often say "Old data may be lost." I > think that's a confusing way to say that old elements are replaced, do we > really want to talk about data loss? Especially "may be lost" ... that doesn't tell the user anything useful. The elements are definitely destroyed. Whether that results in data loss or not depends on the elements, but saying "data may be lost" is too vague to be useful. Under what conditions is it lost? I think we should just remove those sentences.
