4 ms·
The problem with slices in C being added in stdlib would be that they really are a generic data type. It would be similar to atomic types. While C++ could just
by GrumpySloth 3y ago
The problem with slices in C being added in stdlib would be that they really are a generic data type. It would be similar to atomic types. While C++ could just add std::atomic<T>, C needed to add a special construct: _Atomic(T).
C++ already has a slice type. It’s called std::span<T>. Porting it to C would probably require something similar to atomics. At which point I guess you may just as well get on with it and switch to C++.
- pornel 3y agoC++ chose not to have bounds checking on span’s operator[] by default. Like with vector, approximately nobody will use .at(). Buffer overflow vulnerabilities are where programmers thought they don’t need a bounds check, so having this as a choice every time, with the safer option looking worse, is working against it. A nice minimal built-in syntax for spans (like Rust’s slices) could be an incentive to keep the bounds checks, and eventually make bare pointer arithmetic stand out as riskier.
- GrumpySloth 3y agoI think this is more of a social problem with C++. Regardless whether the feature is implemented in the standard library or the core language, the broader C++ community is not going to approve of enabling bounds checks on the bracket operator. And whether this operator is implemented as a builtin or as an overload on an stdlib type is basically transparent to the user. FWIW you can enable bounds checks for the bracket operator by default for STL types in GCC and Clang. So for interfacing with Rust it is both obvious how to translate between slices in Rust and std::span in C++, and you can verify to a degree that this std::span isn’t corrupted on C++ side (to a degree).