Date: Sat, 30 Nov 2019 21:42:04 +0200
On Sat, 30 Nov 2019 at 21:21, Lyberta via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> > So, rather than looking at single-condition cases, we should remember
> > to consider multi-condition ones.
> >
> What? You did 2 checks instead of 6. There's UB lurking.
I would otherwise have sympathy for that, but WTF Lyberta, I did 2
instead of 3. The difference
is (kinda) not in the number, it's in the cost. It should be pointed
out, though, that the 2/3 difference
scales when you have a range; it's 2, as opposed to N, depending on
how many accesses you have.
I have no doubt about your understanding of that cost difference in
current practical implementations,
although I'm generous enough to entertain that my confidence may be
exaggerated. :)
> Anyway. My fundamental opinion is that operator[] should do bounds
> checking while unsafe_at() should not because it is clearly named unsafe.
I.. don't see how unsafe_at walked into this discussion. Perhaps
that's my mistake, honestly,
but I thought this was about adding at() in span because it's already
present in vector and array.
<std-proposals_at_[hidden]> wrote:
> > So, rather than looking at single-condition cases, we should remember
> > to consider multi-condition ones.
> >
> What? You did 2 checks instead of 6. There's UB lurking.
I would otherwise have sympathy for that, but WTF Lyberta, I did 2
instead of 3. The difference
is (kinda) not in the number, it's in the cost. It should be pointed
out, though, that the 2/3 difference
scales when you have a range; it's 2, as opposed to N, depending on
how many accesses you have.
I have no doubt about your understanding of that cost difference in
current practical implementations,
although I'm generous enough to entertain that my confidence may be
exaggerated. :)
> Anyway. My fundamental opinion is that operator[] should do bounds
> checking while unsafe_at() should not because it is clearly named unsafe.
I.. don't see how unsafe_at walked into this discussion. Perhaps
that's my mistake, honestly,
but I thought this was about adding at() in span because it's already
present in vector and array.
Received on 2019-11-30 13:44:39