Re: [STLInterfaces] only three operations?

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-11-27 14:55:18

On Wed, Nov 27, 2019 at 8:38 AM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> Hi,
> While the formal review of STLInterfaces has not yet started, some early
> feedback may be of help.
>
> The idea to implement relational operators from binary operator- for
> random_access_iterator looks too clever for me.

I don't find that to be so.  All those operations (the relops and op-) go
together semantically.  Could you elaborate on why you don't like the
approach?

> Maybe this deserves a
> mention in the documentation it is from operator- that the library will
> generate all relational ops.
>

Quite right.  I'll add this if it's not already documented, or call it out
if it's not obvious enough.

> For non-contiguous random_access_iterators (like in deque) it might be
> suboptimal to do it this way: a directly provided operator== might be
> faster than the one synthesized from operator-. Of course, I can provide
> the 6 relops operators myself, but I could have only 2 if the facade were
> capable of generating operator!= from operator== (and similar). Could
> operator!= for random_access_iterator be generated from operator!= ?
>

It's true that the deque case will be suboptimal.  Here are my
considerations though:

- The point of the library is to reduce the amount of code you must write
to the bare minimum, and basing all the relops on op-  and op== does not
serve that goal.
- Any generated operation (not just the relops) can be replaced by the user
at will, just be having the user define that operation.  In the deque case,
that means defining op-, op==, and op!=.  Deque is not the common case --
most random-access containers are also contiguous.  I want to maintain the
brevity of the common case.  That means the solution is clear
documentation, IMO.

Zach