Boost logo

Boost Users :

Subject: Re: [Boost-users] [containers] defining the insertion point of non-unique keys
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2009-12-18 13:25:00

Daniel James <daniel_james <at>> writes:

> 2009/12/18 Joaquin M Lopez Munoz <joaquin <at>>:
> >
> > No, it's more general than this: assume we've got a container
> > with elements
> >
> >  a1, a2, ... , an, k1, k2, ... , km, b1, b2, ... , bl
> >
> > where k1, ... , km are equivalent (and the rest are not
> > equivalent to these). Put A=[a1,k1), K=[k1,b1), B=[b1,end]. Now
> > if we insert an element equivalent to these in K using hint p,
> > then:
> >
> > * if p is in A, insertion takes place before k1,
> > * if p is in K, insertion takes place before p,
> > * if p is in B, insertion takes place before b1.
> Looking at n3000, only associative containers' 'insert' is specified
> this way. For 'emplace_hint', it says:
> equivalent to a.emplace(std::forward<Args>(args)...).
> [...]
> Implementations are permitted to ignore the hint.
> which I think means that the element is placed at the end of the
> equivalent elements. There are similar definitions for unordered
> containers' 'insert' with hint and 'emplace_hint'. Presumably this is
> a defect?

I think you've spotted a defect in the case of associative
containers. As for the unordered associative containers I don't
see an issue, since insert in this case does not specify in
any case the point of insertion (except to the extent that
equivalent elements must stay together.)

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at