Date: Fri, 29 Nov 2019 00:50:53 +0000
operator[] can’t be marked noexcept as it has a narrow contract and by convention (“Lakos rule”) we do not mark functions with narrow contracts as noexcept…
Notice how operator[] is not marked as noexcept in array, vector, string or string_view!
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Vishal Oza via Std-Proposals
Sent: Thursday, November 28, 2019 6:46 PM
To: sotrdg sotrdg via Std-Proposals <std-proposals_at_[hidden]>
Cc: Vishal Oza <vickoza_at_[hidden]>
Subject: Re: [std-proposals] function at() for span<> that throws exception on out-of-range, like vector and array ::at()
I would first measure if there are performance issues adding at to the span's operator [] other then the performance issues with the at in general. If there are no performance issues with the operator[] then a justification to adding at to std::span is to adding noexcept the operator[] and keeping the exception version with the at operator. This might be another benefit to low latency C++ programmers to use std::span's operator[] as exceptions can be slow. The main issue I see is should the operator[] do any bound checking I am not sure that should be the case with C++ programmers who are looking for the highest performance.
On Thu, Nov 28, 2019 at 5:37 AM Roman Babinicz via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Could we add operators at() to span<> container?
value_type & at(size_type n);
const value_type & at(size_type n) const;
they would have same behaviour as in vector, array - that is throws an
exception if n is outside of size of the container.
1) can we have that?
2) if yes, then should I write a proposal paper or how else to help in this?
Can it make it to C++20?
Imo it is a notable defect that span can not be a drop in replacement
for code taking a (reference to) array/vector that is using at().
3)
By the way, in case of span that has specific size (not dynamic_extent)
we could perhaps have a static assert and the function might be constexpr.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]p.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Notice how operator[] is not marked as noexcept in array, vector, string or string_view!
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Vishal Oza via Std-Proposals
Sent: Thursday, November 28, 2019 6:46 PM
To: sotrdg sotrdg via Std-Proposals <std-proposals_at_[hidden]>
Cc: Vishal Oza <vickoza_at_[hidden]>
Subject: Re: [std-proposals] function at() for span<> that throws exception on out-of-range, like vector and array ::at()
I would first measure if there are performance issues adding at to the span's operator [] other then the performance issues with the at in general. If there are no performance issues with the operator[] then a justification to adding at to std::span is to adding noexcept the operator[] and keeping the exception version with the at operator. This might be another benefit to low latency C++ programmers to use std::span's operator[] as exceptions can be slow. The main issue I see is should the operator[] do any bound checking I am not sure that should be the case with C++ programmers who are looking for the highest performance.
On Thu, Nov 28, 2019 at 5:37 AM Roman Babinicz via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Could we add operators at() to span<> container?
value_type & at(size_type n);
const value_type & at(size_type n) const;
they would have same behaviour as in vector, array - that is throws an
exception if n is outside of size of the container.
1) can we have that?
2) if yes, then should I write a proposal paper or how else to help in this?
Can it make it to C++20?
Imo it is a notable defect that span can not be a drop in replacement
for code taking a (reference to) array/vector that is using at().
3)
By the way, in case of span that has specific size (not dynamic_extent)
we could perhaps have a static assert and the function might be constexpr.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]p.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2019-11-28 18:53:17