C, not C++. Also span had no bounds checking until the introduction of .at() in C++26, which was a very silly thing to do so late in an age where the white house was asking people to use memory safe languages.

▲

TuxSH 4 days ago | parent | next [-]

> Also span had no bounds checking

While there was no reason not to have .at(), lack of bound checks by default isn't a bad thing, as inlined bound checks have the potential to highly pessimize code (esp. in loops); also standard library hardening is a thing.

IMO there's much more value to be had in migrating C code (and pre-C++11 code, too) to C++ (or Rust, depending on one's tastes); RAII - that is to say, the ability to automatically run destructors on scope exit - and in particular shared_ptr/unique_ptr/bespoke intrustive pointers drastically reduce the risks of use-after-free

▲

sirwhinesalot 4 days ago | parent [-]

I like how it's handled in Herb's cpp2/cppfront. If the type implements certain methods (like size()), and you turn on bounds checking, then the indexing operations (which are unsafe) are wrapped in i < c.size() ? c[i] : <throw or abort>.

This way the indexing operation itself doesn't need to have bounds checks and it's easier for the compiler to optimize out the checks or for an "unchecked" section to be requested by the programmer.

▲

aw1621107 3 days ago | parent [-]

> I like how it's handled in Herb's cpp2/cppfront. If the type implements certain methods (like size()), and you turn on bounds checking, then the indexing operations (which are unsafe) are wrapped in i < c.size() ? c[i] : <throw or abort>.

For what it's worth, something similar was proposed in the C++26 core profiles paper [0] and that particular bit got some pushback. From a reponse paper [1]:

> The paper’s suggested approach includes adding bounds checking to containers solely based on a duck-typed deduction using the availability of operators and member functions without knowing for sure what purpose the container serves, what those members do, or even whether the class is, in fact, a container at all. [P3081]’s proposal would cause a wide variety of existing, perfectly valid code to fail unpredictably at run time:

> — Containers that are not zero-indexed

> — Sparse containers

> — Map-like types the compiler cannot detect as being map-like

> — A two-color image where size() is in bytes but for which indexing is by pixel (i.e., by bit)

> — Ring-like containers

> — Containers that automatically grow.

> [P3081] also fails to consider that some library vendors already (and will continue in the future to) choose to put contract preconditions on their operator[], which would result in double and possibly inconsistent checking.

[0]: https://wg21.link/P3081

[1]: https://wg21.link/P3543

	▲	sirwhinesalot 3 days ago \| parent [-]
		Interesting, thanks for sharing!

▲

miropalmu 4 days ago | parent | prev [-]

Oh. Makes sense. My bad.