C++ Logo


Advanced search

Subject: Re: [std-proposals] function at() for span<> that throws exception on out-of-range, like vector and array ::at()
From: Charles Milette (charlesmilette_at_[hidden])
Date: 2019-11-30 10:22:27

On Sat, 30 Nov 2019 at 10:44, Bjorn Reese via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> On 2019-11-30 11:15, Eyal Rozenberg via Std-Proposals wrote:
> > What are the arguments against "at()", other than possibly being redundant?
> That it brings in exceptions, which are disable in many real-time and
> embedded projects.
> For instance P0829 proposes to remove std::array<T>::at() in
> freestanding mode.
> I reckon that the most viable approach forward is to introduce a free
> std::at() function, similar to std::get(). This makes it possible to
> have bounds check for types that do not support them, such as C arrays
> or std::span.
That breaks existing generic code operating on containers expecting an
at() member to
exist (not to mention std::span already won't work with those due to
lacking .at()),
and is much worse to write when chaining:

cont.at(otherCont.at(i)) vs std::at(cont, std::at(otherCont, i))

FYI I also don't like std::get and would have preferred to use
operator[] with the proposed
constexpr parameters on tuples instead.

STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups