From -5278581208369561646 X-Google-Thread: 7894ca11fe,dcc43f3425b0e139 X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 20 Sep 2009 10:20:05 -0500 Return-Path: To: (Usenet) From: "Balog Pal" Newsgroups: comp.std.c++ Subject: Re: Immutability of set elements Organization: ETT newsserver Sender: cppmods@cs.rpi.edu Approved: stephen.clamage@sun.com Message-ID: References: <7.0.0.16.2.20090919120102.05e1e878@aristeia.com> X-Original-Date: Sun, 20 Sep 2009 14:55:47 +0200 X-Submission-Address: std-c++@netlab.cs.rpi.edu Date: Sun, 20 Sep 2009 10:14:46 CST Lines: 45 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-Jk7zXGC2mUODrr1QP8bmDxP/hIHmyG2yzK6alScJT6WHFArq1RDkNjthBLplhMqFy6fnHo6OK/bXrM8!jhQp/K9o0tKodEz2HWGGnnJ2jSY7sJ0wdDCbR3v7Z8qmjLba6zt+acc= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Xref: g2news2.google.com comp.std.c++:1379 "Scott Meyers" > So here's my question: what does it mean for a set key to be > immutable? The commentary on issue 103 suggests that modifying such > keys via mutable members or a const_cast is okay, but presumably doing > so in such a way that would affect the sortedness of the container is > not okay. Does modifying a set key lead to undefined behavior? If > so, in all cases, or only under some conditions, e.g., when the > sortedness of the container is affected? > > All illumination appreciated. Good question. As I read the rationale if the issue, the resolution is to shift the interface toward constness (thus supposedly make it easier to use correctly and harder to use incorrectly without triggering a diagnostic...). So for then next STL, ESTL item 22 could be milded down to intentional cases and attached restrictions. But the proposed text change is IMO suboptimal to say at best. After reading the whole DR and the section several times, my interpretation is that 'immutable' here is supposed to mean what a 'const &' to a not-originally-const object the usual C++ way. But the word standing alone does not imply that (and the std text does not drag in the DR rationale to figure out), neither is it defined properly. Addition to p3 is a clear requirement that in the lifetime of the container keys shall not be changed to break ordering. Having that fixed, my preference for the rest would be to have: - map's key NOT being const (as changing such thing is UB by other parts of std) - interfaces that retrieve keys of all the assiciative containers return const &. With all that I'd think all the use cases are fixed for good, from both usability and (defend-murphy-)safety standpoint. -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]