Hacker News new | past | comments | ask | show | jobs | submit login

Well if you're starting a project now that you expect to live for many years, there's the issue of C++ safety now, and C++ safety in the foreseeable future.

Right now projects have the option of building with the santizers (particularly the address sanitizer) enabled, right? The executable would be slower and less memory efficient, but it would eliminate most of the critical CVEs that exploit invalid memory access. Is there a reason Google couldn't provide alternative builds of Chrome with the santizers enabled?

As for the foreseeable future, you can come up with arguments (convincing or otherwise) that C++ will be effectively memory (and data race) safe in the foreseeable future. At some point, presumably the core guidelines lifetime checker will enforce memory safety. To what degree it will in practice is a matter of speculation, but in theory it could be as effective as the Rust compiler.

Just as an observation, if you peruse the chromium source code, from a modern C++ perspective, there seems to me to be an alarming prevalence of raw pointers. (Probably understandable as chromium's been around for a while.) C++ is now a very powerful language, and if (memory) safety is a priority it is already practical (and performant[1]) to avoid the use of notoriously unsafe elements like raw pointers and unchecked buffers in favor of safer alternatives. (It is similarly practical to avoid data race prone elements[2].)

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#multithread...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: