El 08/04/2017 a las 12:59, Ion Gaztañaga via Boost escribió:
On 08/04/2017 10:54, Joaquin M López Muñoz via Boost wrote:
Shouldn't you also provide
void adopt_sequence(unique_range_t, sequence_type &&seq); void adopt_sequence(ordered_range_t, sequence_type &&seq);
for flat_map/set?
It looks a bit asymmetric against multi[set/map] containers which only require ordered_unique (their own invariant). It's realistic that a user that orders the sequence externally does not want to / can't erase duplicates before calling the "risky" version of adopt_sequence?
The situation looks perfectly logical to me: multi[set/map] keeps one invariant, namely sortedness, whereas set/map keeps two, sortedness and uniqueness, and it is in principle thinkable that data be given back to the container with none, one or both invariants preserved, hence the four different overloads: * adopt_sequence(seq) --> sort and eliminate duplicates * adopt_sequence(unique_range_t,seq) --> sort * adopt_sequence(ordered_range_t,seq) --> eliminate duplicates * adopt_sequence(ordered_unique_range_t,seq) --> do nothing One could potentially collapse these in two by neglecting to use the info that one of the two invariants is preserved, but the solution would not be optimal performancewise. Joaquín M López Muñoz