public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
[not found] <bug-24061-11415@http.gcc.gnu.org/bugzilla/>
@ 2005-10-02 8:58 ` pcarlini at suse dot de
2005-10-09 10:34 ` cvs-commit at gcc dot gnu dot org
2005-10-09 10:36 ` pcarlini at suse dot de
2 siblings, 0 replies; 9+ messages in thread
From: pcarlini at suse dot de @ 2005-10-02 8:58 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from pcarlini at suse dot de 2005-10-02 08:58 -------
In the light of a discussion on the LWG reflector (in a nutshell, 6.3.1p8 and
6.3.1p12 together imply that rehashing is not allowed during erase), it seems
we have just to implement the resolution of issue 6.19. Will take care of it.
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2005-10-02 08:58:14
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
[not found] <bug-24061-11415@http.gcc.gnu.org/bugzilla/>
2005-10-02 8:58 ` [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change pcarlini at suse dot de
@ 2005-10-09 10:34 ` cvs-commit at gcc dot gnu dot org
2005-10-09 10:36 ` pcarlini at suse dot de
2 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2005-10-09 10:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-09 10:34 -------
Subject: Bug 24061
CVSROOT: /cvs/gcc
Module name: gcc
Changes by: paolo@gcc.gnu.org 2005-10-09 10:34:47
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/include/tr1: hashtable unordered_map unordered_set
Added files:
libstdc++-v3/testsuite/tr1/6_containers/unordered/erase:
24061-map.cc
24061-multimap.cc
24061-multiset.cc
24061-set.cc
libstdc++-v3/testsuite/tr1/6_containers/unordered/insert:
24061-map.cc
24061-multimap.cc
24061-multiset.cc
24061-set.cc
Log message:
2005-10-09 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/24061 (issue 6.19)
* include/tr1/hashtable (struct node_const_iterator, struct
hashtable_const_iterator): New, add const variants to enable separate
overloadings for iterator and const_iterator in unordered_set and
unordered_multiset (as required by issue 6.19).
(class hashtable): Change the mutable_iterators template parameter
to constant_iterators and adjust throughout the logic.
(hashtable::insert(iterator, const value_type&), erase(iterator)
erase(iterator, iterator)): New, as per issue 6.19.
(hashtable::m_erase(node*, node**)): New, called by erase(iterator)
and erase(const_iterator).
(hashtable::Insert_Conv_Type): New, used by insert(iterator,
const value_type&) and insert(const_iterator, const value_type&)
to delegate the work to insert(const value_type&).
* include/tr1/unordered_map (class unordered_map, unordered_multimap):
Adjust typedefs.
* include/tr1/unordered_set (class unordered_set, unordered_multiset):
Likewise.
* testsuite/tr1/6_containers/unordered/erase/24061-map.cc: New.
* testsuite/tr1/6_containers/unordered/erase/24061-multimap.cc: New.
* testsuite/tr1/6_containers/unordered/erase/24061-multiset.cc: New.
* testsuite/tr1/6_containers/unordered/erase/24061-set.cc: New.
* testsuite/tr1/6_containers/unordered/insert/24061-map.cc: New.
* testsuite/tr1/6_containers/unordered/insert/24061-multimap.cc: New.
* testsuite/tr1/6_containers/unordered/insert/24061-multiset.cc: New.
* testsuite/tr1/6_containers/unordered/insert/24061-set.cc: New.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3126&r2=1.3127
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/hashtable.diff?cvsroot=gcc&r1=1.12&r2=1.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/unordered_map.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/unordered_set.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/erase/24061-map.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/erase/24061-multimap.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/erase/24061-multiset.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/erase/24061-set.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/insert/24061-map.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/insert/24061-multimap.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/insert/24061-multiset.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/insert/24061-set.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
[not found] <bug-24061-11415@http.gcc.gnu.org/bugzilla/>
2005-10-02 8:58 ` [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change pcarlini at suse dot de
2005-10-09 10:34 ` cvs-commit at gcc dot gnu dot org
@ 2005-10-09 10:36 ` pcarlini at suse dot de
2 siblings, 0 replies; 9+ messages in thread
From: pcarlini at suse dot de @ 2005-10-09 10:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from pcarlini at suse dot de 2005-10-09 10:36 -------
Fixed for 4.1.
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
2005-09-25 23:59 [Bug c++/24061] New: " atavory at gmail dot com
` (4 preceding siblings ...)
2005-09-26 22:23 ` atavory at gmail dot com
@ 2005-09-27 7:21 ` pcarlini at suse dot de
5 siblings, 0 replies; 9+ messages in thread
From: pcarlini at suse dot de @ 2005-09-27 7:21 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2005-09-27 07:20 -------
(In reply to comment #4)
> So, IMHO, this isn't giving up consistency; it's just reflecting inherent
> inconsistency through an inconsistent interface.
I see your point. I don't know. This is really matter for the LWG: are you
willing to send a message to the reflector and/or get in touch with Matt
and Howard privately? In my opinion, there are two different options, either
implement in TR1 the tentative resolution of issue 6.19 (strictly speaking
would be consistent with the rest of the library, even the details of the
current wording for erase - I think you agree - even if it=erase(it) would
not make sense, but where it's spelled out that *must*, necessarily?), or
completely undo it with the sensible rationale that you provided. Just let
me know how you want to proceed...
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
2005-09-25 23:59 [Bug c++/24061] New: " atavory at gmail dot com
` (3 preceding siblings ...)
2005-09-26 10:03 ` pcarlini at suse dot de
@ 2005-09-26 22:23 ` atavory at gmail dot com
2005-09-27 7:21 ` pcarlini at suse dot de
5 siblings, 0 replies; 9+ messages in thread
From: atavory at gmail dot com @ 2005-09-26 22:23 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
2005-09-25 23:59 [Bug c++/24061] New: " atavory at gmail dot com
` (2 preceding siblings ...)
2005-09-26 9:43 ` pcarlini at suse dot de
@ 2005-09-26 10:03 ` pcarlini at suse dot de
2005-09-26 22:23 ` atavory at gmail dot com
2005-09-27 7:21 ` pcarlini at suse dot de
5 siblings, 0 replies; 9+ messages in thread
From: pcarlini at suse dot de @ 2005-09-26 10:03 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2005-09-26 10:03 -------
To be clear: my impression is that the resolution of DR130 was dictated by and
large by consistency and that the current wording for the iterator returned by
erase would be Ok also for unordered containers (besides all the other
containers).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
2005-09-25 23:59 [Bug c++/24061] New: " atavory at gmail dot com
2005-09-26 0:00 ` [Bug libstdc++/24061] " pinskia at gcc dot gnu dot org
2005-09-26 9:16 ` pcarlini at suse dot de
@ 2005-09-26 9:43 ` pcarlini at suse dot de
2005-09-26 10:03 ` pcarlini at suse dot de
` (2 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: pcarlini at suse dot de @ 2005-09-26 9:43 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2005-09-26 09:42 -------
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?!?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
2005-09-25 23:59 [Bug c++/24061] New: " atavory at gmail dot com
2005-09-26 0:00 ` [Bug libstdc++/24061] " pinskia at gcc dot gnu dot org
@ 2005-09-26 9:16 ` pcarlini at suse dot de
2005-09-26 9:43 ` pcarlini at suse dot de
` (3 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: pcarlini at suse dot de @ 2005-09-26 9:16 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2005-09-26 09:16 -------
Then, issue 6.19 of N1837 (Library Extension Technical Report - Issues List)
should be also updated... Certainly, this inconsistency between the (associative,
see DR130) containers and the new unordered containers is annoying...
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |austern at gcc dot gnu dot
| |org
BugsThisDependsOn| |24054
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
2005-09-25 23:59 [Bug c++/24061] New: " atavory at gmail dot com
@ 2005-09-26 0:00 ` pinskia at gcc dot gnu dot org
2005-09-26 9:16 ` pcarlini at suse dot de
` (4 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-09-26 0:00 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-10-09 10:36 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-24061-11415@http.gcc.gnu.org/bugzilla/>
2005-10-02 8:58 ` [Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change pcarlini at suse dot de
2005-10-09 10:34 ` cvs-commit at gcc dot gnu dot org
2005-10-09 10:36 ` pcarlini at suse dot de
2005-09-25 23:59 [Bug c++/24061] New: " atavory at gmail dot com
2005-09-26 0:00 ` [Bug libstdc++/24061] " pinskia at gcc dot gnu dot org
2005-09-26 9:16 ` pcarlini at suse dot de
2005-09-26 9:43 ` pcarlini at suse dot de
2005-09-26 10:03 ` pcarlini at suse dot de
2005-09-26 22:23 ` atavory at gmail dot com
2005-09-27 7:21 ` pcarlini at suse dot de
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).