How is that memory safe? Even vector out of bounds index is not memory safe.

You can access a vector with a function that throws an exception if you so desire

You can also just write no code at all if you so desire. It certainly won't cause any memory issues that way. (Hint: What you yourself decide to write or refrain from writing is not the problem. You're not they only person who ever worked on this legacy codebase, and you want guarantees but default, not having to check every line of code in the entire project.)

no you just have to write a githook with some static analysis, like literally everyone who does proper c++. Safety hasn't been an issue in c++ for more than a decade. It's just a made up thing by people who don't use the language but only want to hate.

Go look at the CVEs and github issues of modern C++ codebases. Your statement is nonsense. Chromium is still plagued by use after free. How high do you set the bar? Which codebases are we allowed to look at?

I had that exact discussion with someone else a while ago. And when you actually go through the chromium memory bugs, it's 100% avoidable with an absolute baseline of competence and not using ancient bugs. It's unfair that C++ always has to compete in its state from 1990s against languages in their current iteration.

That's why I asked what the bar was? If Google is writing shitty C++ even with the world's eyes on their code base, who is doing it right? No one writing anything sufficiently complicated that's for sure.

However you feel about this issue: It's pretty widely known that google is bad at c++. Most codebases will be of significantly higher quality.

Google chrome must be one of the most used (in terms of CPU time) C++ software in the world right now. That means it's been fuzz tested (by the developers as well as by the users and also the random websites that gives it garbage html and javascript) extensively. I can only think of the Linux kernel that is more widely used, and Linux is not C++.

Since you seem to be very good at c++, can you point to a "significantly higher quality" c++ projects please? I'd like to see what it looks like.

> Since you seem to be very good at c++, can you point to a "significantly higher quality" c++ projects please?

Not the parent commenter, but there are quite a few very high-quality C++ projects out there.

- LLVM

- KDE projects

- CMake

- Node.js

- OpenJDK

I don't think popular or large correlate with code quality. In fact it's probably the opposite. It uses pretty ancient c++ stuff, which immediately disqualifies it from bring of high quality in regards to the cpp code (and also is the cause for their security bugs)

>It's pretty widely known that google is bad at c++

No, it's not. This is literally the first time I hear about this. Do you have any sources to support your claim, especially in light of the fact that Google has written and contributed to some of the largest and most important C++ codebases in existence?

It's funny; I spent a couple of hours last week helping some students debug out-of-bounds indices in their Rust code.

I've written bugs that would have been caught by the compiler in a memory-safe language. I think the last time was maybe in 2012 or 2013? I still write plenty of bugs today but they're almost all logic errors that nothing (short of AI tools) could have caught.

vector.at() is memory safe. You get a choice. Easy to ban [] if you cannot statically prove it is safe.

C++11 isn't the most memory safe language, but C++11 is a lot safer than older versions, and C++23 is better yet. I'm expecting true memory safety in C++26 (time will tell), but it will be opt-in profiles which isn't ideal.

This is not idiomatic C++ in any C++ standard. You can also just replace vector with map so the brackets insert, but that isn't either.

Prefer at to [] is standard where I write C++. map is not standard because vector is almost always much faster random access in the real world (that is n is normally small enough that a linear search is faster than a binary search because of caching)

Oops, shared_ptr circular reference.

Oops, null smart pointer.

Oops, UB made my reference null.

Oops, invalidated iterator.

Oops, aliased pointers.

Oops, race condition.

Oops, recursion.

Oops, moved-from object is partially formed.

I heard about Rust recently.