From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2019-11-27 15:45:15
> 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk