From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-11-27 21:48:55
År., 27 lis 2019 o 15:54 Zach Laine <whatwasthataddress_at_[hidden]>
> On Wed, Nov 27, 2019 at 8:38 AM Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
>> 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
I am sorry. I was writing that mail in a hurry an I failed to communicate
my thoughts clearly. I do like your approach. In fact, I find it really
illuminating. It is just that I find it so novel, that it could easily be
taken for a mistake. I was staring at the docs for a long while, where it
said the only operations I need for random access iterator was *, -, and
+=, and I concluded that there must be some some error in the script that
produces the documentation and the guy surely wanted to type operator== as
well. Only after looking at the implementation did I realize that it was
not a mistake.
Hence my suggestion: make it very clear in the documentation that relops
are generated from operator- for random access iterators.
>> 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.
I agree with aiming at the minimum boilerplate from the user, and I agree
that non-contiguous random access iterators are so rare that they could be
sacrificed. However, I believe that what I propose does not compromise your
goals. As Hans pointed demonstrated, if you implement operator== using
operator-, and then implement operator!= using operator== (rather than
using operator-), then all your use cases work as before, but the
additional gain is that if I additionally volunteer to provide my own
operator== (because it is faster) you can give me operator!= for free.
Does this make sense?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk