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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net