On Tue, Dec 17, 2019 at 12:39 AM Rainer Deyke via Boost < boost@lists.boost.org> 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