Re: [STLInterfaces] only three operations?

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-11-27 17:07:04

On Wed, Nov 27, 2019 at 9:45 AM Hans Dembinski <hans.dembinski_at_[hidden]>
wrote:

>
> > On 27. Nov 2019, at 15:55, Zach Laine via Boost <boost_at_[hidden]>
> wrote:
> >
> > On Wed, Nov 27, 2019 at 8:38 AM Andrzej Krzemienski via Boost <
> > boost_at_[hidden]> wrote:
>
> >> 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.
>
> I think Andrzej made a good point, it should be possible to override
> automatically generated operators by adding a minimal number of extra
> operators, minimal demo:
>
> https://godbolt.org/z/zaFpBU

Sure, that's easy.  Modifying sequence_container to generate overloads
based on op== and/or op- is not so easy. :)   As I said, if you find the
op==/op!= case to be less optimal when implemented in terms of op-, it's
just a matter of adding your own op==, and a one-liner op!=.  That's not a
great deal of burden on the user.

Zach