If a language prevents you from doing stuff like that, this always comes at a cost, since it has to do the work for you, almost always. This is additional overhead you can get rid of in C++ and therefore gain a lot of performance. But that again comes with more responsibility on the developer’s side and you might need to implement appropriate checks yourself where needed.
You’ve missed the context. There are occasions in Rust where you have to use more boilerplate code which you wouldn’t have to implement in C++ to that extent.
But saying that C++ is free of boilerplate is of course ridiculous, if you are not able to heavily leverage templates, CRTPs, macros and alike.
sure, maybe, but performance doesn’t matter for deciding if a language is memory-safe or not. And C++ isn’t memory-safe by any commonly used interpretation of that word.
You may of course decide that the downsides of memory-safety aren’t worth it for your use-case, that is a separate issue
I think it boils down, how we define “memory safe”. C++ is perfectly memory safe, if you know what you’re doing. A lot of people don’t. Which is why Rust was born. that doesn’t make C++ a memory-unsafe language. It just demands more responsibility from the user. A design philosophy that comes with a lot more flexibility than Rust can offer.
Which is fine. Both languages have their perks. But saying C++ isn’t memory safe, while Rust is, is in my opinion just plainly wrong. Besides, with “unsafe” Rust inherently already the door for memory issues.
Modern C++ practises and dev patterns can handle most memory issues in C++ pretty easily. Consider smart pointers for example, or RAII.
It’s not the language’s fault if it is used wrong.
You’re right. Thanks for the links. Although I still think that C++ provides the tools to enable memory-safe programming, I guess the lack of enforcement makes it inherently memory-unsafe.
If the standard is “you know what you’re doing and never make mistakes”, then all languages are memory safe. All you’re doing is arguing against memory safety as a concept by redefining the term in such a way that it becomes meaningless.
Which language would you say is not memory safe then? Is there any serious language out there where you should expect memory issues if you don’t make any mistakes?
If a language prevents you from doing stuff like that, this always comes at a cost, since it has to do the work for you, almost always. This is additional overhead you can get rid of in C++ and therefore gain a lot of performance. But that again comes with more responsibility on the developer’s side and you might need to implement appropriate checks yourself where needed.
Every source I’ve seen has shown rust and c++ to be very similar in terms of performance.
It’s not just about runtime performance, but also about coding flexibility, and for example also reduction of boilerplate.
Ah yes, I love how C++ is has so little boilerplate. Sometimes I can even write several statements in a row without any!
You’ve missed the context. There are occasions in Rust where you have to use more boilerplate code which you wouldn’t have to implement in C++ to that extent.
But saying that C++ is free of boilerplate is of course ridiculous, if you are not able to heavily leverage templates, CRTPs, macros and alike.
sure, maybe, but performance doesn’t matter for deciding if a language is memory-safe or not. And C++ isn’t memory-safe by any commonly used interpretation of that word.
You may of course decide that the downsides of memory-safety aren’t worth it for your use-case, that is a separate issue
I think it boils down, how we define “memory safe”. C++ is perfectly memory safe, if you know what you’re doing. A lot of people don’t. Which is why Rust was born. that doesn’t make C++ a memory-unsafe language. It just demands more responsibility from the user. A design philosophy that comes with a lot more flexibility than Rust can offer.
Which is fine. Both languages have their perks. But saying C++ isn’t memory safe, while Rust is, is in my opinion just plainly wrong. Besides, with “unsafe” Rust inherently already the door for memory issues.
Modern C++ practises and dev patterns can handle most memory issues in C++ pretty easily. Consider smart pointers for example, or RAII.
It’s not the language’s fault if it is used wrong.
https://en.m.wikipedia.org/wiki/Memory_safety
https://www.memorysafety.org/docs/memory-safety/
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
https://www.cisa.gov/news-events/news/urgent-need-memory-safety-software-products
why do you want to redefine what the term means? why does it hurt to admit that C++ is not memory safe? It’s not about your weakness.
You’re right. Thanks for the links. Although I still think that C++ provides the tools to enable memory-safe programming, I guess the lack of enforcement makes it inherently memory-unsafe.
Point taken, I’ll stop saying that.
If the standard is “you know what you’re doing and never make mistakes”, then all languages are memory safe. All you’re doing is arguing against memory safety as a concept by redefining the term in such a way that it becomes meaningless.
Yupp. I’ve changed my stance on this.
Since C++ doesn’t enforce memory safe programming paradigms, it is inherently memory unsafe.
Which language would you say is not memory safe then? Is there any serious language out there where you should expect memory issues if you don’t make any mistakes?
No. I changed my mind just very recently throughout this discussion.
I agree now that the lack of enforcement of memory safe techniques in C++ makes it inherently memory-unsafe.
That doesn’t change the fact though that it’s possible to write memory safe code, if you know what you’re doing, use the right patterns, classes etc…