«

On May 19, 3:31*pm, Andy Champ <no....@nospam.invalid> wrote:
> Have I understood this correctly?
>
> Andy

Yup. I had the exact same problem recently. By
[lib.associative.reqmts] point 5: Keys in an associative
container are immutable.

And in a set, the value is also the key.

--Jonathan

Jonathan Lee <> wrote:
> Yup. I had the exact same problem recently. By
> [lib.associative.reqmts] point 5: Keys in an associative
> container are immutable.
>
> And in a set, the value is also the key.

That's why we have std::map: It's like a set, but with a mutable part on
each "key". It's what you should use when you want to change a part of the
key which isn't used to determine its ordering.

On May 21, 3:12*pm, Andy Champ <no....@nospam.invalid> wrote:
> Jonathan Lee wrote:
> Leigh Johnston wrote:
>
> As I went back through the posts to forward them to my work account (no
> NNTP) it occurred to me - Are you guys related
>
> Andy

The near name reversal is indicative of the fact that one of us is
from a parallel universe and has a goatee.

You don't get to know which one.

--Jonathan

On May 20, 5:00*am, Juha Nieminen <nos...@thanks.invalid> wrote:
> Jonathan Lee <jlee...@uwo.ca> wrote:
> > Yup. I had the exact same problem recently. By
> > [lib.associative.reqmts] point 5: Keys in an associative
> > container are immutable.
>
> > And in a set, the value is also the key.
>
> * That's why we have std::map: It's like a set, but with a mutable part on
> each "key". It's what you should use when you want to change a part of the
> key which isn't used to determine its ordering.

I would say that's why we have boost::multi_index_container and
boost::intrusive containers. std::map it seems to me speaks
with a forked tongue, pair<key, value>. Although it takes a
little more effort, using an alternative to map avoids the
useless "first" and "second" terminology required by maps.
You can get by with maps in small programs, but how things
are named is more important in larger programs. I think
that some projects start out using maps and although they
would benefit from switching to an alternative, they lack
the resources to go back and rework things.


Brian Wood
http://webEbenezer.net
(651) 251-9384