Re: [Boost-users] [containers] defining the insertion point of non-unique keys

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> fmail.co.uk> writes:

> 
> 2009/12/18 Joaquin M Lopez Munoz <joaquin <at> tid.es>:
> >
> > 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