C++ Software Security Sins: Basic Issues
cppstories.com
cppstories.com
> Array new and delete
> When you write new in your applications, you are creating unmanaged objects, and you are then required to call delete later on if you don’t want to risk leaks. So don’t use new and delete at all, as this is considered a C++ bad practice. Better yet, working in modern C++ allows you to use smart pointers and Standard library container classes that make it easier to match every new with exactly one delete.
The text is reasonable, but why is the heading "array new and delete"? There is a difference between new/delete and new[]/delete[], and calling delete[] on something created by new or vice versa is indeed going to cause problems. But that problem (and hence the section title) is more or less orthogonal to what the section body talks about.
Edit: The corresponding slide in the presentation does talk specifically about this kind of mismatch. It also comes to the same conclusion as the text ("just use the STL"). The connection between title and body was apparently lost in translation.
Maybe as more general feedback, I'm getting a strange vibe from this blog. Lots of "top 5 <C++ thing>" posts, links to Patreon-gated articles, ads for blog-owner-written books... Which would all be fine, but that plus an inconsistent summary of someone else's talk raises a lot of warning signs for me.
Obviously it's bogus for the language to let you say you want an array of 26 chars and then treat that as a reasonable place to write an unknown number of characters, but that's a language fault.
I mean, given what is intended in the examples is a string, obviously you should use an actual string. But if you want an array, you should be able to use an array for that, and it's silly that instead you're asked to use a substitute.
(1) https://github.com/microsoft/STL/blob/62137922ab168f8e23ec1a...
But on the other hand, I already am splitting hairs. C++ comes with actual arrays, which lack bells and whistles, adding the bells and whistles to a class named "array" in the STL instead does not add them to actual arrays. If it did that would be a fine fix, but it doesn't.
Rust users who've told the compiler that their function wants, for example, an array of 26 chars can cheerfully assume in the function that the array has 26 chars in it. The compiler won't let anybody call that function with anything else so it'll be fine. It can make sense to do that, although perhaps not with exactly 26 chars.
C++ users can write a pretty similar looking function signature, including that size constraint - but, a C++ compiler just ignores the integer 26 and silently gives them a pointer to what may or may not be some number of chars, even though that's clearly not what the author intended. They need to write something quite different if they want the compiler to look after this constraint, and if they knew to do that they wouldn't be in this mess in the first place.
As to your point... C++ doesn't really work that way. The STL can't add methods to "actual arrays" as you call them, and the compiler can't really do it either. You could extend a compiler to do it but then it wouldn't be C++, strictly speaking.
Some of the other issues like type coercion between arrays and pointers is both not that big of a deal, has well known solutions, and changing would break so much could it's not feasible to do.
While there's some verbosity to the STL (the error messages are worse than anything else) that's just what programming in C++ is like. It is not terse.
This is tautological. C++ has subsequently added all sorts of features, including new operators and keywords. It chose not to actually fix arrays, either when instituting std:array or since. "You can't do that in C++" would have been an equally reasonable thing to say about the spaceship operator (and then C++20 added that), or a for loop inside a constant function (and then C++14 added that) and it remains today just as reasonable a thing to say about various features we can expect to see in C++23 or beyond.
What you are suggesting is altering either the semantics of the language (no C++, including the STL, may define methods for foreign types, which include primitive/built-in types like arrays), or altering the contract between the compiler and the language (the implementation does not define any methods for primitive types, with the exception of a handful of things that must be implemented by the compiler, like sizeof).
Now I'm not saying its impossible for raw arrays to have nice features added in the future. Just that it's an uphill battle that has subtleties you're ignoring. It's not as simple as allowing some extra syntax that previously was disallowed.
Other stuff like forbidding coercion between arrays of the same type will never be added to the specification because it does more than allow new programs to be written, it results in old programs being forbidden. The last change I can recall doing this was the removal of auto_ptr and deprecation of some niche features dating to the 80s that no one actually used.
If you agree it's possible to fix this "in the future" then either you imagine some as yet non-existent technology is needed, or you have to agree it was already possible to fix this in the past and they chose not to. As I said.
> Just that it's an uphill battle that has subtleties you're ignoring.
Everything in C++ has subtleties that I'm ignoring. Trivial fixes to the STL result in multi-hour wrangling, the C++ back compatibility story is a black hole nightmare, and so any new feature work comes down to who is willing to wrestle with the bear. But remember, I am not the one who came here to tell people about how "No even vaguely competent C++ programmer" would use a core language primitive.
A powerful desire to ignore these subtleties is why I don't write C++. I was actually starting to worry that I might have to learn (modern) C++ in the last few years, but Rust averts that.
std::string would work in a similar way, except it would be `const`
Rust is a young language, perhaps in twenty years we'll know that editions weren't powerful enough, but it seems like a good start. This year will see a new edition (Rust 2021) with a handful of such changes, such as requiring you always write 1..=9 not the historical alternative 1...9 when you mean that the range should be exactly 1,2,3,4,5,6,7,8,9.