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]>
> > On 27. Nov 2019, at 15:55, Zach Laine via Boost <boost_at_[hidden]>
> > 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
> >> 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
> > at will, just be having the user define that operation. In the deque
> > that means defining op-, op==, and op!=. Deque is not the common case --
> > most random-access containers are also contiguous. I want to maintain
> > 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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk