To be clear i think it still worth it and a big step forward, but it isn’t a silver bullet. It mostly just helps indicate where problems with memory safety could happen within the subsection of code that you control.
I’ve heard the “70% of bugs are memory safety bugs” statistic a lot but I’ve never heard any data about what portion of those bugs Rust actually prevents? Because with “unsafe” the amount is clearly not “all”. Is it half? A quarter, three quarters?
I think that potentially makes the comparative advantage of Rust a lot less clear. If it only removes a third of that 70%, then you’re talking about a 20% reduction in bugs… in exchange for rewriting everything and changing your tooling, etc. It’s not obvious to me that putative trade off is actually worth it versus investing more in testing, QA, fuzzing, etc.
This is factually incorrect. I write rust code for a CDN and we have unsafe exactly twice in the entire codebase and it’s to integrate with a c++ binding for a dependency that hasn’t been rewritten yet
I think that potentially makes the comparative advantage of Rust a lot less clear. If it only removes a third of that 70%, with the remaining two thirds living in unsafe code, then you’re talking about a 20% total reduction in bugs
Sure, when you asspull some random numbers that tell you what you want to hear, you can make anything seem reasonable.
Meanwhile, here's what some people who actually did the research have to say:
We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.
This is true, but I also feel like it's a bit vacuous or a fundamental assumption of non-scripting languages. At some point you have to interface with a native library, the operating system, or hardware.
As we learn things in CS, we sometimes discover a language allows us to shoot ourselves, and everyone who uses software developed in that language, in the foot. We develop new languages that don't have those problems. The community should migrate to those new, more secure, languages. Then we find new weaknesses & vulnerabilities. Repeat.
I'm torn. I see people interpeting this as him saying "just don't write memory bugs", but I don't think that's acurate. Instead I think he's saying "make not writing bugs easier for yourself by using 'modern' C++ features that manage memory for you", and claims that, empirically, this approach significantly reduces bugs. I believe that.
When I write C++, I almost never write new and delete or use raw pointers; I use vectors, and spans, and string_views, etc. and it does make it easier to avoid writing bugs. However, it doesn't make it impossible to write them (or, to be frank, even difficult), and other languages do make it impossible.
Recently, I had an issue where my C++ code was working ony development system, but exhibiting corruption on another system. It turns out I wrote a stupid bug: I stored a reference to an element in a vector, then later I extended the vector, which invalidated the reference I later used. I know that extending a vector invalidates references, but that operation was so far away in the code from where I took the reference that I didn't even realize I was extending the vector while holding a reference. Software systems are complex, too complex for a person to hold in their mind all at once, and the C++ compiler couldn't help me avoid the mistake, because of the design of the C++ language makes it impossible for even the compiler, which can hold the whole program in memory, to reliably check for the mistake.
Meanwhile, the numerous proposals to make it possible to statically prevent memory bugs in C++ have all failed, because they all end up weaking C++'s biggest strength, seamless C interop. That's a huge strength, because there are a whole lot of libraries with C interfaces, and I agree that it's practically non-negotiable, because if you don't need C interop, why are you using C++ rather than a language which doesn't need seamless C interop and already prevents memory bugs?
So I guess I see his point of view. He's tired of people focusing on memory safety issues that C++ ultimately can never solve, while rejecting imperfect but practical proposals that would improve the situation without completely solving it. I don't really like it — it's just not a good situation for the greater software ecosystem to be in — but I can't say it's wrong.
In my experience significant portion of C++ developers have developed selective blindness to compiler warnings, like netizens have selective blindness to ads on websites
Warnings are kinda annoying. Especially if you depend on a library and there are warnings in that library you're more or less stuck. Especially if warnings are in headers (or it's a header-only library), then from the compilers perspective it's all coming from your project.
You often don't want to spend the effort to fix the library errors (if you even could), so you're just going to have to live with warnings now.
CMake automatically uses -isystem or equivalent for IMPORTED targets. You also have SYSTEM on a bunch of commands that achieve the same result, because people are so hell bent on treating 3rd party code as their own instead of using a package manager like Conan or vcpkg.
Sure, but you don't care about 3rd party library errors so you just disable it for those. Just selectively disable warnings with pragma push/pop.
// middleware.hpp
#pragma once
#pragma push
#pragma disable any relevant warnings
#include <somethirdpartyheaders.h>
#pragma pop
Then every file in our codebase includes that instead of the library directly. Works like a charm and we can build our multi-million line codebase with all errors known to the compiler on as well as -Werror.
He also says that in the interview. In fact the quote in the thumbnail about “I should have fought harder for that” is about him trying to get the compiler to give deprecation warnings for using raw pointers and other bad memory practices in C++26 but others on the C++ committee pushed back.
But C++ keeps adding new features which make it easy to create dangling references. There's been some progress with lambdas -- with explicit this capture -- but coroutines make it really easy again, as do ranges.
And no, compiler warnings/linters/static analyzers have not proven up to the task for now...
It's simple: just use a very precise, specific subset of the language, figure out what to expand that subset to as new language versions drop, be highly skilled, work only with equally highly skilled people, and ensure your entire dependency chain follows similar practices.
The problem is that we've got tons of evidence that this is insufficient. Yes, smart pointers can help with some UAFs. Using spans instead of bare arrays can help with some OOB access. But these local rules don't sum to global safety. Especially in a world of separate compilation where your compiler has very minimal global reasoning capabilities.
I've been really saddened by how Bjarne has responded to this whole conversation, almost like he is taking it as a personal slight that C++ is criticized for a lack of memory safety. And instead of recognizing that C++ is what it is and that people are just trying to keep improving things he quibbles over the definition of memory safety and offers guidance that clearly will not work.
He seems irritated by this question: why ask about something that was completely solved 15 years ago in C++11 and will probably be finally solved in 3 years in C++29?
I don't understand why he wouldn't just say: "Yes, the language has these problems. Yes, we have solved some of them. Some of them we can't solve without losing backward compatibility."
"Yes, the language has these problems. Yes, we have solved some of them. Some of them we can't solve without losing backward compatibility."
Yep. It is obvious that the committee has chosen backwards compatibility (including binary compatibility) as a priority. That's fine. It is an acceptable design choice. Where it gets annoying is when Bjarne seems incredulous as to why people would advocate for Rust or whatever because of different priorities.
lol, him comparing "guidelines" (aka "devlopers, please don't write code with memory-safety bugs!") to rust compile-time checks is just wild and pure copium :D
It's still wild. The reason rust needed extra syntax for mut, borrows and lifetimes is exactly because you can't figure those things out automagically with c++ syntax, it's not enough metadata.
I didn't bother watching the video because I've seen enough Stroustrup rants about memory safety but I assume this is about his safety profiles proposal. He has constantly described it as "subset of a superset" (which is a meaningless description by itself) in the sense that you grow the language to introduce safe versions of coding patterns and then define a "safe" subset of the language. Whole motivating idea being that it's easier to migrate a "partially unsafe" C++20 library to a "safe" C++?? library the compiles with safety profiles xyz enabled than to convert that same library to safe Rust.
TBF, when C++ was first created, such things weren't so much of a concern as now. It provided a way to achieve great performance, be excellent for low-level programming while also offering higher-level features like classes or templates.
A case could be made that such things could've been introduced later, but doing so without breaking compatibility would not have been straightforward. And of course, getting everyone to agree on its design would be another major hurdle.
It's an entirely different world now than then. Not only was memory safety not as important back then, but any language which didn't let you control allocations and had garbage collection would not have been seen as a useful systems language. There were systems like that using Smalltalk, LISP, etc. and they their resource needs saw them perceived as toys by much of the industry. Processors were too slow and memory sizes too small to "waste memory" on the things you need for memory safety.
Things are a lot different now.
Your last paragraph is also key. If you made C++ work that way it just wouldn't mesh with C at all. And that might have killed C++ at the start so it wouldn't have mattered much to the industry what it tried to do.
Memory safety was just as important then as it is now. As an example, once we realized how many memory errors were introduced due to the lack of bounds checking in strcpy(), it's use was discouraged in favor of functions that didn't blinding copy past the end of allocated memory. That was in the 90s, around the same time C++ was just taking off.
The only difference between then and now is that we have more tooling to help with it, in the form of linters, checkers, and languages that are built for memory safety.
C++ was created in 1985. strlcpy was released in 1998. Smashing The Stack For Fun And Profit was published in 1996. And exploits of mem safety issues didn't become a hugely widespread concern until we had the explosion in networked software in the late 90s.
The only difference between then and now is that we have more tooling to help with it, in the form of linters, checkers, and languages that are built for memory safety.
Completely wrong. As I already indicated with how we have so much more compute capability to absorb the overhead of implementing memory safety in the language.
Memory safety was not as important back then because it was seen as something we could not afford. You could have a system that runs well enough but doesn't have memory safety. Or you could have a system that has memory safety but it just cannot handle heavy compute work because it consumed too many resources just running code and managing memory safety.
This is not to say memory errors didn't exist, but simply that having to put up with the possibility of having them produced a more workable system than fixing the problem with a memory safe language.
Given memory safety doesn't fix TOCTOU problems I'm not sure where we are headed next. Nothing is as safe as we think it is, even if it's written in a memory safe language. We still have to rely on programmers doing the right thing and that's a bit scary with things like Anthropic's new automated exploit finder.
how. you can malloc a pointer to memory block and wander that pointer anywhere. I guess some sort of pointer locked to that memory block that would not go outside ? And as for null terminated strings, same sort of rule.
The pointer from malloc is stored in a container like std::vector or such, and only accessed through carefully written methods of that container class.
Strings should be used through std::string. Let that class worry about null termination.
If you want to make that joke it should be something like “Hitler talks about jewish culture” or “Hitler talks about equality”. You got it the wrong way round.
At one job, I mentored a fellow C++ programmer to favor using pointer-free code wherever possible (which was almost everywhere). In doing so, I explained to her, you would eliminate all program crashes that were due to mishandled pointers -- which was at least 95% of all crashes. Programming without pointers also eliminates virtually all memory leaks.
She was one of the few programmers who took my advice -- most other programmers refused to stop using their beloved pointers, and as a result inadvertently coded in a fair amount of crashes and memory leaks in whatever C++ code they touched.
The woman I mentored even mentioned to me that she once interviewed for a C++ programming position at another company. The interviewer asked her, "How do you eliminate crashes in your programs?" She responded, "By not using pointers." The interviewer didn't understand what she was talking about.
More than half of all [programmers] don't write modern C++.
I completely agree. So many C++ programmers (as of a few years ago) love using pointers everywhere in their code.
I realized years ago that over 95% of errors that caused our C++ programs to crash were due to pointer errors. So when I wrote/modified programs without using pointers (and used references instead, or objects on the stack), I eliminated 95% of crashes!
I would advise my co-workers how to write pointer-free code, but most programmers didn't care to; they loved their pointers and didn't want to stop using them. Even though I got a reputation for writing programs that almost never crashed, only one or two programmers ever took my advice of not using pointers. The rest happily worked away with their beloved pointers, creating crash-prone code.
SeungminHong@reddit
How to write good code
Step 1: don't write bad code
DeGamiesaiKaiSy@reddit
Follow the dos and don'ts from his cpp book :)
SeungminHong@reddit
You think programmers can read?
MehYam@reddit
What's step 0?
muntaxitome@reddit
profit
Mognakor@reddit
Don't write code
SeungminHong@reddit
Step 0: if you are planning on writing bad code, don’t even start
Shoddy-Childhood-511@reddit
"Is there a way to get the compiler to just prevent people doing all those risky things?"
Yes, Rust's lifetimes & borrow checker.
The_Northern_Light@reddit
Yes, but with a big asterisk.
Rust would be unusable without “unsafe”.
To be clear i think it still worth it and a big step forward, but it isn’t a silver bullet. It mostly just helps indicate where problems with memory safety could happen within the subsection of code that you control.
I’ve heard the “70% of bugs are memory safety bugs” statistic a lot but I’ve never heard any data about what portion of those bugs Rust actually prevents? Because with “unsafe” the amount is clearly not “all”. Is it half? A quarter, three quarters?
I think that potentially makes the comparative advantage of Rust a lot less clear. If it only removes a third of that 70%, then you’re talking about a 20% reduction in bugs… in exchange for rewriting everything and changing your tooling, etc. It’s not obvious to me that putative trade off is actually worth it versus investing more in testing, QA, fuzzing, etc.
rexspook@reddit
This is factually incorrect. I write rust code for a CDN and we have unsafe exactly twice in the entire codebase and it’s to integrate with a c++ binding for a dependency that hasn’t been rewritten yet
srdoe@reddit
Sure, when you asspull some random numbers that tell you what you want to hear, you can make anything seem reasonable.
Meanwhile, here's what some people who actually did the research have to say:
https://blog.google/security/rust-in-android-move-fast-fix-things/
antiduh@reddit
This is true, but I also feel like it's a bit vacuous or a fundamental assumption of non-scripting languages. At some point you have to interface with a native library, the operating system, or hardware.
NatureBoyJ1@reddit
As we learn things in CS, we sometimes discover a language allows us to shoot ourselves, and everyone who uses software developed in that language, in the foot. We develop new languages that don't have those problems. The community should migrate to those new, more secure, languages. Then we find new weaknesses & vulnerabilities. Repeat.
Longjumping_Cap_3673@reddit
I'm torn. I see people interpeting this as him saying "just don't write memory bugs", but I don't think that's acurate. Instead I think he's saying "make not writing bugs easier for yourself by using 'modern' C++ features that manage memory for you", and claims that, empirically, this approach significantly reduces bugs. I believe that.
When I write C++, I almost never write new and delete or use raw pointers; I use vectors, and spans, and string_views, etc. and it does make it easier to avoid writing bugs. However, it doesn't make it impossible to write them (or, to be frank, even difficult), and other languages do make it impossible.
Recently, I had an issue where my C++ code was working ony development system, but exhibiting corruption on another system. It turns out I wrote a stupid bug: I stored a reference to an element in a vector, then later I extended the vector, which invalidated the reference I later used. I know that extending a vector invalidates references, but that operation was so far away in the code from where I took the reference that I didn't even realize I was extending the vector while holding a reference. Software systems are complex, too complex for a person to hold in their mind all at once, and the C++ compiler couldn't help me avoid the mistake, because of the design of the C++ language makes it impossible for even the compiler, which can hold the whole program in memory, to reliably check for the mistake.
Meanwhile, the numerous proposals to make it possible to statically prevent memory bugs in C++ have all failed, because they all end up weaking C++'s biggest strength, seamless C interop. That's a huge strength, because there are a whole lot of libraries with C interfaces, and I agree that it's practically non-negotiable, because if you don't need C interop, why are you using C++ rather than a language which doesn't need seamless C interop and already prevents memory bugs?
So I guess I see his point of view. He's tired of people focusing on memory safety issues that C++ ultimately can never solve, while rejecting imperfect but practical proposals that would improve the situation without completely solving it. I don't really like it — it's just not a good situation for the greater software ecosystem to be in — but I can't say it's wrong.
BenchEmbarrassed7316@reddit
tldr
C++ Memory Safety Guide: Just don’t write code that violates memory safety.
dukey@reddit (OP)
It's a bit more like, stop writing legacy code, or just C in C++.
BenchEmbarrassed7316@reddit
If you don't want anyone to use an outdated API or language features, you mark them as deprecated and delete them after a while.
dukey@reddit (OP)
Or at least give an unsafe compile warning
TomKavees@reddit
In my experience significant portion of C++ developers have developed selective blindness to compiler warnings, like netizens have selective blindness to ads on websites
🫠
Drugbird@reddit
Warnings are kinda annoying. Especially if you depend on a library and there are warnings in that library you're more or less stuck. Especially if warnings are in headers (or it's a header-only library), then from the compilers perspective it's all coming from your project.
You often don't want to spend the effort to fix the library errors (if you even could), so you're just going to have to live with warnings now.
cdb_11@reddit
In all major compilers you can disable warnings for just some specific section of code.
gmes78@reddit
Your project is set up wrong. If you use
-isysteminstead of-Ito include third-party headers, you won't get warnings for them.Plazmatic@reddit
Yeah that doesn't work as consistently as it should, cmake generally handles this for you until it doesn't
helloiamsomeone@reddit
CMake automatically uses
-isystemor equivalent forIMPORTEDtargets. You also haveSYSTEMon a bunch of commands that achieve the same result, because people are so hell bent on treating 3rd party code as their own instead of using a package manager like Conan or vcpkg.TeraFlint@reddit
It's time they meet
-Werror.gimpwiz@reddit
Werror Wall Wextra and so forth, from day 1.
apadin1@reddit
Great in theory, a pain in the ass in practice.
lestofante@reddit
Because writing "modern" c++ is a pain in the ass :/
Zueuk@reddit
any sufficiently advanced C++ is indistinguishable from pain in the ass
Casalvieri3@reddit
Good luck with that.
emfloured@reddit
Especially when using 3rd party libraries like C library :D
spookje@reddit
Sure, but you don't care about 3rd party library errors so you just disable it for those. Just selectively disable warnings with pragma push/pop.
Then every file in our codebase includes that instead of the library directly. Works like a charm and we can build our multi-million line codebase with all errors known to the compiler on as well as -Werror.
YellowBunnyReddit@reddit
My favorite ad blocker:
-wmark_99@reddit
That's what the Profiles proposal is (also mentioned in the podcast):
https://open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3589r0.pdf
AresFowl44@reddit
It's that but an optional compiler flag
VictoryMotel@reddit
It's not outdated APIs, it's using language features instead of libraries when it isn't necessary.
rysto32@reddit
I mean sure, if you want to give up on using C libraries in C++ code.
apadin1@reddit
He also says that in the interview. In fact the quote in the thumbnail about “I should have fought harder for that” is about him trying to get the compiler to give deprecation warnings for using raw pointers and other bad memory practices in C++26 but others on the C++ committee pushed back.
matthieum@reddit
If only it was sufficient...
I mean, it definitely helps, certainly.
But C++ keeps adding new features which make it easy to create dangling references. There's been some progress with lambdas -- with explicit this capture -- but coroutines make it really easy again, as do ranges.
And no, compiler warnings/linters/static analyzers have not proven up to the task for now...
wallstop-dev@reddit
It's simple: just use a very precise, specific subset of the language, figure out what to expand that subset to as new language versions drop, be highly skilled, work only with equally highly skilled people, and ensure your entire dependency chain follows similar practices.
asmx85@reddit
Can someone toss me a lifebuoy – i am drowning in sarcasm :D
UncleMeat11@reddit
The problem is that we've got tons of evidence that this is insufficient. Yes, smart pointers can help with some UAFs. Using spans instead of bare arrays can help with some OOB access. But these local rules don't sum to global safety. Especially in a world of separate compilation where your compiler has very minimal global reasoning capabilities.
just-bair@reddit
Idk how to use C++ properly so the only functionality of it I use is classes. Using libraries in C++ is a pain in the ass tough
MrPinkPotato@reddit
Should we also stop using legacy code from std, boost and most other 11-compatible libraries?:)
UncleMeat11@reddit
I've been really saddened by how Bjarne has responded to this whole conversation, almost like he is taking it as a personal slight that C++ is criticized for a lack of memory safety. And instead of recognizing that C++ is what it is and that people are just trying to keep improving things he quibbles over the definition of memory safety and offers guidance that clearly will not work.
BenchEmbarrassed7316@reddit
He seems irritated by this question: why ask about something that was completely solved 15 years ago in C++11 and will probably be finally solved in 3 years in C++29?
I don't understand why he wouldn't just say: "Yes, the language has these problems. Yes, we have solved some of them. Some of them we can't solve without losing backward compatibility."
UncleMeat11@reddit
Yep. It is obvious that the committee has chosen backwards compatibility (including binary compatibility) as a priority. That's fine. It is an acceptable design choice. Where it gets annoying is when Bjarne seems incredulous as to why people would advocate for Rust or whatever because of different priorities.
Ictoan42@reddit
I've noticed this being a trend in how Bjarne tends to respond to criticism of C++
_predator_@reddit
skill-issue.mp4
jakeStacktrace@reddit
Your video is not playing for me.
r_yahoo@reddit
It's only plat for it's creator
n_lens@reddit
Might be a memory issue!
mawesome4ever@reddit
I forgot to press play
DestroyedLolo@reddit
For sure, you're having a memory issue.
xhvrqlle@reddit
downloadmoreram.com to the rescue!
Vesuvius079@reddit
Easy. Just requires that you and everyone who ever worked on the project from the beginning of time knew and used the right approach to doing so.
Abrissbirne66@reddit
I already knew from this paper that he doesn't appreciate memory safety like in Rust properly.
Pharisaeus@reddit
lol, him comparing "guidelines" (aka "devlopers, please don't write code with memory-safety bugs!") to rust compile-time checks is just wild and pure copium :D
Abrissbirne66@reddit
It seems that he is referring to compile time checking if the guidelines are met so the comparison is not that wild.
Pharisaeus@reddit
It's still wild. The reason rust needed extra syntax for mut, borrows and lifetimes is exactly because you can't figure those things out automagically with c++ syntax, it's not enough metadata.
Gorzoid@reddit
I didn't bother watching the video because I've seen enough Stroustrup rants about memory safety but I assume this is about his safety profiles proposal. He has constantly described it as "subset of a superset" (which is a meaningless description by itself) in the sense that you grow the language to introduce safe versions of coding patterns and then define a "safe" subset of the language. Whole motivating idea being that it's easier to migrate a "partially unsafe" C++20 library to a "safe" C++?? library the compiles with safety profiles xyz enabled than to convert that same library to safe Rust.
ForeverIntoTheLight@reddit
TBF, when C++ was first created, such things weren't so much of a concern as now. It provided a way to achieve great performance, be excellent for low-level programming while also offering higher-level features like classes or templates.
A case could be made that such things could've been introduced later, but doing so without breaking compatibility would not have been straightforward. And of course, getting everyone to agree on its design would be another major hurdle.
happyscrappy@reddit
It's an entirely different world now than then. Not only was memory safety not as important back then, but any language which didn't let you control allocations and had garbage collection would not have been seen as a useful systems language. There were systems like that using Smalltalk, LISP, etc. and they their resource needs saw them perceived as toys by much of the industry. Processors were too slow and memory sizes too small to "waste memory" on the things you need for memory safety.
Things are a lot different now.
Your last paragraph is also key. If you made C++ work that way it just wouldn't mesh with C at all. And that might have killed C++ at the start so it wouldn't have mattered much to the industry what it tried to do.
atxgossiphound@reddit
Memory safety was just as important then as it is now. As an example, once we realized how many memory errors were introduced due to the lack of bounds checking in strcpy(), it's use was discouraged in favor of functions that didn't blinding copy past the end of allocated memory. That was in the 90s, around the same time C++ was just taking off.
The only difference between then and now is that we have more tooling to help with it, in the form of linters, checkers, and languages that are built for memory safety.
Bjarne's right, though, just write good code.
UncleMeat11@reddit
C++ was created in 1985. strlcpy was released in 1998. Smashing The Stack For Fun And Profit was published in 1996. And exploits of mem safety issues didn't become a hugely widespread concern until we had the explosion in networked software in the late 90s.
happyscrappy@reddit
Completely wrong. As I already indicated with how we have so much more compute capability to absorb the overhead of implementing memory safety in the language.
Memory safety was not as important back then because it was seen as something we could not afford. You could have a system that runs well enough but doesn't have memory safety. Or you could have a system that has memory safety but it just cannot handle heavy compute work because it consumed too many resources just running code and managing memory safety.
This is not to say memory errors didn't exist, but simply that having to put up with the possibility of having them produced a more workable system than fixing the problem with a memory safe language.
Given memory safety doesn't fix TOCTOU problems I'm not sure where we are headed next. Nothing is as safe as we think it is, even if it's written in a memory safe language. We still have to rely on programmers doing the right thing and that's a bit scary with things like Anthropic's new automated exploit finder.
NatureBoyJ1@reddit
" just write good code."
But it helps a lot if the language prevents you from writing self-destructive code - or at least makes it very difficult.
Milanium@reddit
It is coming by default for C++ 29, is my takeaway here.
malakon@reddit
how. you can malloc a pointer to memory block and wander that pointer anywhere. I guess some sort of pointer locked to that memory block that would not go outside ? And as for null terminated strings, same sort of rule.
victotronics@reddit
The pointer from malloc is stored in a container like std::vector or such, and only accessed through carefully written methods of that container class.
Strings should be used through std::string. Let that class worry about null termination.
Zueuk@reddit
he is not wrong 🤷♂️
Jack_Faller@reddit
"Hitler talks about anti-Semitism."
Abrissbirne66@reddit
If you want to make that joke it should be something like “Hitler talks about jewish culture” or “Hitler talks about equality”. You got it the wrong way round.
Godd2@reddit
What in Godwin's Law is going on here?
superxpro12@reddit
i think its just a very crass joke about someone who is talking about memory safety while birthing a language that is not very memory safe friendly.
Jack_Faller@reddit
I should also add that, having now watched the video, his response of "is not a problem" is also quite fitting.
ForeverIntoTheLight@reddit
Hitler lives rent-free in some people's heads, long after his mortal coil fell apart.
SpaceAviator1999@reddit
At one job, I mentored a fellow C++ programmer to favor using pointer-free code wherever possible (which was almost everywhere). In doing so, I explained to her, you would eliminate all program crashes that were due to mishandled pointers -- which was at least 95% of all crashes. Programming without pointers also eliminates virtually all memory leaks.
She was one of the few programmers who took my advice -- most other programmers refused to stop using their beloved pointers, and as a result inadvertently coded in a fair amount of crashes and memory leaks in whatever C++ code they touched.
The woman I mentored even mentioned to me that she once interviewed for a C++ programming position at another company. The interviewer asked her, "How do you eliminate crashes in your programs?" She responded, "By not using pointers." The interviewer didn't understand what she was talking about.
SpaceAviator1999@reddit
I completely agree. So many C++ programmers (as of a few years ago) love using pointers everywhere in their code.
I realized years ago that over 95% of errors that caused our C++ programs to crash were due to pointer errors. So when I wrote/modified programs without using pointers (and used references instead, or objects on the stack), I eliminated 95% of crashes!
I would advise my co-workers how to write pointer-free code, but most programmers didn't care to; they loved their pointers and didn't want to stop using them. Even though I got a reputation for writing programs that almost never crashed, only one or two programmers ever took my advice of not using pointers. The rest happily worked away with their beloved pointers, creating crash-prone code.
encse@reddit
This guy lost me at object slicing.
Blue_Moon_Lake@reddit
Object slicing should be opt-in rather than opt-out...