The word "immutable" appears exactly once in N2914.  It's at the end
of [associative.reqmts]/5:

 Keys in an associative container are immutable.

Don't be fooled by the general-sounding nature of this edict:  it
really applies only to set.  Keys in a map are already defined to be
const (which presumably implies immutability, but it's hard to say,
because "immutable" in this context is never defined), and the hashed
containers aren't associative containers, they're unordered
associative containers, a completely different thing.  Ahem.  But I
digress.

The sentence above comes straight from the resolution of Library Issue
103, which was opened in 1998 and, from what I can tell, resolved by
2001 ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1291.html#103
), yet was not incorporated into TC1.  But again I digress.

The commentary on Library Issue 103 says:

>If users need to modify elements, it is possible to use mutable
>members or const_cast.

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.

Thanks,

Scott



--
[ 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                      ]

"Scott Meyers" <smeyers@aristeia.com>
> 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                      ]

Scott Meyers wrote:
>
>> If users need to modify elements, it is possible to use mutable
>> members or const_cast.
>
> 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?
>

 From what I understand, some people would like to have the possibility
of updating parts of the stored data, that is not actually part of the
key. With a user supplied comparison-functor, parts of a stored
structure might have no effect on the ordering.

For example, you might have an existing data structure that already
contains the key value. Ordinarily you would store this in a map, but
to avoid storing the key twice, you use a set with a special
comparator.

Anyone actually doing this, is supposedly skilled enough to use a
proper const_cast when updating the non-key data.  :-)


Bo Persson



--
[ 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                      ]