From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-12-17 15:05:03
On Tue, Dec 17, 2019 at 12:39 AM Rainer Deyke via Boost <
boost_at_[hidden]> wrote:
> On 16.12.19 23:19, Zach Laine via Boost wrote:
> > - operators < and == can be provided, since the requirements of these
> >> functions already suggest a default implementation. The user can still
> >> override the provided implementation if a more efficient implementation
> >> is possible. If it is for some reason desirable to create a container
> >> without operator <, an additional policy argument could be added to
> >> container_interface.
> >>
> >
> > These are all provided; I think you just missed them.
>
> operator== is listed in Table 1.3, and in the User-Defined column of
> Table 1.4. The note in Table 1.8 also says that operator== is required
> to be user-defined. So if the library provides it, then the
> documentation does not reflect this.
>
Ah, I see. Fortunately, that's only a doc problem. For a container C with
value_type T, if operator==(T, T) is defined, then operator==(C, C) is
defined. Similarly, if operator<(T, T) is defined, you get operator<(C, C)
from that.
If you provide a custom operator<(C, C), or use the one defined via
operator<(T, T) -> operator<(C, C), you get all the other relational
operators for C. This was communicated poorly. I'll fix that.
Zach