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