I disagree with the blanket statement “C++ isn’t memory safe”. C++ provides the tools for writing memory-safe code, but it does not enforce it by default.
This is such a weird take. C++ isn’t memory safe. The blanket statement is… true. You say as much in the second sentence.
With C++, you retain full control over memory management and can choose the best tool for the job. You’re not boxed into a strict ownership model that may force refactoring or add extra layers of abstraction.
You have full control in Rust too, at least to the same extent as C++. Rust isn’t memory safe either. Rust is just the opposite of C++ in the approach to safety: you opt in to being unsafe with the unsafe construct instead of being unsafe by default. They’re just different paradigms. I’d actually argue that you don’t have full control in either language unless you opt in to it, modern C++ tries very hard to abstract away memory management. You can write an entire program without a single new or malloc, which is pretty great.
Sure, mistakes can happen, but with proper practices and modern C++ features you can achieve a level of safety that meets most needs without sacrificing the expressiveness and efficiency you might require in complex systems.
This is just simply not true and is consistently proven incorrect every time an aspect of C++'s memory unsafety is exploited. I work in security and I still, in 2025, exploit memory corruption. The best developers money can buy still make mistakes with C and C++.
Besides that: which conventions do you mean?
The way you have to interact with smart pointers for example:
Double free, but compiles without warning. It’s convention to not use unique_pointer’s constructor, not enforced.
#include<iostream>#include<string>intmain(int argc, char** argv){
constchar* c;
{
std::string a("HelloThisIsAHeapString");
c = a.c_str();
}
std::cout << c << std::endl;
}
Use after free. No compiler error or warning, it’s convention to not maintain references to C++ string data, not enforced.
That’s all fine, whatever, but these are conventions. We’ve shot ourselves in the foot a million times and come up with our own guard rails, but the developer needs to know all of them to not make the mistake.
This is such a weird take. C++ isn’t memory safe. The blanket statement is… true. You say as much in the second sentence.
I suppose we need to make definitions clearer. C++ is memory safe in the sense that you can write memory safe code. It doesn’t enforce memory safety though. But not doing that is not the language’s fault. If someone jumps with a bike from a flying airplane, it’s not the bike’s fault that they will not land safely. It’s the misuse of the bike.
The best developers money can buy still make mistakes with C and C++.
I’d argue those weren’t the best developers then. However, I don’t want to get ridiculous. I see that there are problems in the common use of C++. Although I can’t share that from my experience due to usually proper usage, thorough testing use of additional tools, there is surely a need for aiding C++ devs with writing safe code. I know of the corresponding security concerns as well as probably everyone else in the C++ community.
There are proposals to improve on that. Some of those might already come with C++26. Stroustrup’s favourite are Profiles to provide and enforce further guarantees, while others propsed an extension like Safe C++. Whereever the future will take us with C++, I’m confident that this issue will be sufficiently solved one day.
There was a time when C++ wasn’t even designed for multi-processor systems, lol. That was redesigned pretty late. Much has changed and it will continue to improve as C++ continues to mature.
Edit:
Just saw your convention examples after I’ve sent my reply. Idk why it wasn’t displayed before.
Regarding the double free:
It’s clear from the documentation that this returns a raw pointer.
Regarding the use after free:
I really don’t want to sound arrogant as this is a simple example of course, but that is such an obvious mistake and looks like a topic which is covered in C++ beginner classes. To me, this is almost on the same level as dividing by zero and wondering about resulting bugs.
but the developer needs to know all of them to not make the mistake
Yes. Not every language is as user-friendly as python. With more flexibility come more risks but also more rewards if you’ve mastered it. It depends on what you want to do and how much you’re willing to invest.
I would at least expect a professional dev to rtfm. Which itself is apparently already a problem. But, in the end of the day we want to use tools, which are effective and easy to use. So sure, point taken. I refer to the section before my edit regarding developments upon improving such aspects in C++.
I suppose we need to make definitions clearer. C++ is memory safe in the sense that you can write memory safe code. It doesn’t enforce memory safety though. But not doing that is not the language’s fault. If someone jumps with a bike from a flying airplane, it’s not the bike’s fault that they will not land safely. It’s the misuse of the bike.
saying that C++ is memory safe because it’s possible to use it in a memory safe manner is like saying jumping out of a plane with the bike is safe, because it’s possible to safely land (with a parachute and a lot of training).
you always repeat that C++ is memory safe because its possible, and that “misuse” is “not its fault”.
first, you are quite simply redefining what does memory safety mean. you basically say bombs are safe because they can be safely defused with the expertise.
second, do you really need to misuse it to get unsafe code? it does not warn anywhere. not in the instructions, not in the compiler output.
third, its no one’s “fault” that c++ is not memory safe. That’s not a fault of c++. like its not a fault of factories that you have to wear safery gear when working inside because otherwise you may get injured more severely. this is just a property of C++, not a judgement
I’d argue those weren’t the best developers then.
oh no, my suspension was correct, you are really thinking that you are the perfect coder who jever makes any mistakes. It does not make sense to argue with you
The definition of “a memory safe programming language” is not in debate at all in the programming community. I have no idea why you’re trying to change it.
I’d argue those weren’t the best developers then
This is incredibly arrogant, and, tbh, ignorant.
You missed the point of the examples: those aren’t necessarily “easy mistakes” to make and of course a UAF is easy to spot in a 4 line program, the point is that there is no language construct in place to protect from these trivial memory safety issues. With respect to the “obviousness” of the std::string mistake, if you instead consider an opaque interface that requires a constchar* as an input, you have no idea if it is going to try to reference of that pointer or not past the lifetime of the std::string. If you can’t see past the simplicity of an example to the bigger picture that’s not on me.
This is such a weird take. C++ isn’t memory safe. The blanket statement is… true. You say as much in the second sentence.
You have full control in Rust too, at least to the same extent as C++. Rust isn’t memory safe either. Rust is just the opposite of C++ in the approach to safety: you opt in to being unsafe with the
unsafeconstruct instead of being unsafe by default. They’re just different paradigms. I’d actually argue that you don’t have full control in either language unless you opt in to it, modern C++ tries very hard to abstract away memory management. You can write an entire program without a singlenewormalloc, which is pretty great.This is just simply not true and is consistently proven incorrect every time an aspect of C++'s memory unsafety is exploited. I work in security and I still, in 2025, exploit memory corruption. The best developers money can buy still make mistakes with C and C++.
The way you have to interact with smart pointers for example:
#include <memory> int main(int argc, char** argv) { std::unique_ptr<int> a = std::make_unique<int>(1); std::unique_ptr<int> b(a.get()); }Double free, but compiles without warning. It’s convention to not use
unique_pointer’s constructor, not enforced.#include <iostream> #include <string> int main(int argc, char** argv) { const char* c; { std::string a("HelloThisIsAHeapString"); c = a.c_str(); } std::cout << c << std::endl; }Use after free. No compiler error or warning, it’s convention to not maintain references to C++ string data, not enforced.
That’s all fine, whatever, but these are conventions. We’ve shot ourselves in the foot a million times and come up with our own guard rails, but the developer needs to know all of them to not make the mistake.
I suppose we need to make definitions clearer. C++ is memory safe in the sense that you can write memory safe code. It doesn’t enforce memory safety though. But not doing that is not the language’s fault. If someone jumps with a bike from a flying airplane, it’s not the bike’s fault that they will not land safely. It’s the misuse of the bike.
I’d argue those weren’t the best developers then. However, I don’t want to get ridiculous. I see that there are problems in the common use of C++. Although I can’t share that from my experience due to usually proper usage, thorough testing use of additional tools, there is surely a need for aiding C++ devs with writing safe code. I know of the corresponding security concerns as well as probably everyone else in the C++ community.
There are proposals to improve on that. Some of those might already come with C++26. Stroustrup’s favourite are Profiles to provide and enforce further guarantees, while others propsed an extension like Safe C++. Whereever the future will take us with C++, I’m confident that this issue will be sufficiently solved one day.
There was a time when C++ wasn’t even designed for multi-processor systems, lol. That was redesigned pretty late. Much has changed and it will continue to improve as C++ continues to mature.
Edit: Just saw your convention examples after I’ve sent my reply. Idk why it wasn’t displayed before.
Regarding the double free: It’s clear from the documentation that this returns a raw pointer.
Regarding the use after free:
I really don’t want to sound arrogant as this is a simple example of course, but that is such an obvious mistake and looks like a topic which is covered in C++ beginner classes. To me, this is almost on the same level as dividing by zero and wondering about resulting bugs.
Yes. Not every language is as user-friendly as python. With more flexibility come more risks but also more rewards if you’ve mastered it. It depends on what you want to do and how much you’re willing to invest. I would at least expect a professional dev to rtfm. Which itself is apparently already a problem. But, in the end of the day we want to use tools, which are effective and easy to use. So sure, point taken. I refer to the section before my edit regarding developments upon improving such aspects in C++.
saying that C++ is memory safe because it’s possible to use it in a memory safe manner is like saying jumping out of a plane with the bike is safe, because it’s possible to safely land (with a parachute and a lot of training).
you always repeat that C++ is memory safe because its possible, and that “misuse” is “not its fault”.
first, you are quite simply redefining what does memory safety mean. you basically say bombs are safe because they can be safely defused with the expertise.
second, do you really need to misuse it to get unsafe code? it does not warn anywhere. not in the instructions, not in the compiler output.
third, its no one’s “fault” that c++ is not memory safe. That’s not a fault of c++. like its not a fault of factories that you have to wear safery gear when working inside because otherwise you may get injured more severely. this is just a property of C++, not a judgement
oh no, my suspension was correct, you are really thinking that you are the perfect coder who jever makes any mistakes. It does not make sense to argue with you
deleted by creator
The definition of “a memory safe programming language” is not in debate at all in the programming community. I have no idea why you’re trying to change it.
This is incredibly arrogant, and, tbh, ignorant.
You missed the point of the examples: those aren’t necessarily “easy mistakes” to make and of course a UAF is easy to spot in a 4 line program, the point is that there is no language construct in place to protect from these trivial memory safety issues. With respect to the “obviousness” of the
std::stringmistake, if you instead consider an opaque interface that requires aconst char*as an input, you have no idea if it is going to try to reference of that pointer or not past the lifetime of thestd::string. If you can’t see past the simplicity of an example to the bigger picture that’s not on me.