Boost logo

Boost :

Subject: Re: [boost] [container][set, map, flat_set, flat_map, +multi_xxx] operator< and operator== seems to ignore custom KeyCompare
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-07-18 03:27:36


On 18-07-2013 01:07, Evgeny Panasyuk wrote:
> 18.07.2013 1:22, Ion Gaztañaga:
> > (taken from N3680) Table 98 — Optional container operations
> [...]
>> -> Operational semantics lexicographical_compare
>> (a.begin(), a.end(), b.begin(), b.end())
>>
>> -> Assertion/note: pre: < is defined for values of T. < is a total
>> ordering relationship.

So std::vector<T*> or std::set<T*> is not guaranteed to work?

> [...]
>> I guess using Compare for associative containers' operator < could
>> perfectly work it won't be the standard behaviour.

Yeah, it's definitely a breaking change.

>
> + also, here (Table 98) < is **total ordering**, while "23.2.4
> Associative containers" says:
> "
> 2. Each associative container is parameterized on Key and an ordering
> relation Compare that induces a **strict weak ordering** (25.4) on
> elements of Key. In addition, map and multimap associate an arbitrary
> mapped type T with the Key. The object of type Compare is called the
> comparison object of a container.
> "

Well, one could argue that the internal ordering is a different concept
than the semantics of the comparison operators. My motivation was more
that I can't think of a situation where I don't want the KeyCompare to
be used for <. Still, we can't know what compare to use for ==, unless
we require it to rely on < (which may be slower).

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk