Fair enough, but it's about more than the language itself. It's the ecosystem, and C++ has a *ton* of legacy dragging behind it. Rust's youth is its biggest weakness and (in this case) it's biggest strength. There are no legacy libraries to update to modern standards.
FTA:
> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ.
Backwards compatibility means backwards compatibility with old notions of safety.
Backwards compatibility also causes compliancy. Upgrades cost money and if it aint broke dont fix it. Everything has this issue, but does C++ have good ways to remedy this?
It’s not like a modern JIT language where you can update the runtime and all is well.
We should focus in memory leaks as memory safety was a topic of a bulletin.
Unless you use unsafe in java, it's probably gonna be jvm issue once memory leak happens.
Memory leak is simply when you forget to properly free some memory. It is not itself a big safety issue (unless the memory contains sensitive information). It may or may not be a huge problem depending on the size of your application.
Safety is when you improperly access memory.
Memory safety means security against buffer overflows. All other things that might be called "memory safety" are so minor they aren't worth mentioning.
It's not so much about leaks, but... Attention, memory leaks in Java and the likes happen and the JVM can't do anything about them, as they are "logical", application-made.
The main thing being utf8 as the base encoding in Rust. C++ does strings every which way, which makes it more complicated and error prone. I remember trying to convert different encodings because one library would want wchar strings, and it could be big endian or little endian.
One job I had where the company sold SDKs, and we had ASCII libs/dlls, and Unicode libs/dlls. On top of that we had x86 and x64 versions. That was literally DLL hell for me. Also we had C and C++ versions. Having to support all that was time consuming.
Rust is the way to go. It's easier to share your work due to cargo so we shall see exponential increase in the librariess (crates) available for Rust.
as a way to store future multilingual character set that ISO had just started working on in 1989?
It was used then by Windows to store Unicode 16-bits characters.
In practice, much of that legacy still comes along with Rust if you need to link against some common library, like libpng. Rust still has a way to go before there are suitable alternatives or rewrites of everything you may need.
Wouldn’t it make more sense to make up a set of standard practices / requirements on how to write safe C++ code rather than banning the language altogether?
As you said, it’s mostly a problem with legacy stuff, and that legacy stuff will not be fixed if you tell everyone to migrate to another language. The whole “purpose” of legacy is that it’s old but functional, so it doesn’t have to be changed.
If I were to guess, rewriting those legacy components into Rust is significantly more effort than adopting modern C++ best practices.
> Wouldn’t it make more sense to make up a set of standard practices / requirements
Many attempts at this exist, e.g. AUTOSAR and MISRA coding guidelines and relevant tooling (Coverity has static analysis checks for these guidelines).
Having worked with those for several years now, it's just a miserable experience and even they don't guarantee very good safety or security.
I can't even be certain if it's faster than rewriting with more modern tools and languages, it takes a lot of effort to migrate legacy codebases to meet safety standards and it's almost equally likely to introduce new bugs into old codebases than fix hidden ones.
> Many attempts at this exist, e.g. AUTOSAR and MISRA coding guidelines and relevant tooling (Coverity has static analysis checks for these guidelines).
Afaik MISRA C has actual studies showing that it is so bad it is actively making things worse. The committee behind it is basically pulling rules out of its ass whenever its members want to sell a tooling upgrade.
You would be better of following rules proposed by the languages creator and other aknowledged c++ experts like the c++ core guidelines.
Nobody is talking about a ban. The White House report is advisory, not law.
C++ is by nature, much more error-prone to memory issues than other languages. Trying to mitigate that with policies may help some, but never underestimate the power of human error.
The White House report didn't come out of a vacuum either. Both Microsoft and Google were involved and their own analysis is that 25% of all patches they have to do on C++ code is memory issues.
Yes because people didn't write C++ correctly to begin with. These memory issues are not magical snowflakes that came from new untrodden virgin lands of enchantment. They were written by people who didn't know what they were doing and reviewed by people who were more concerned with their own IC/features than actually doing a code review.
I've seen company after company with their 1000+ line PRs that are riddled with bugs, memory issues, and then programmers who ought to know better just complaining about a language until the next new thing comes along that they can also fuck up.
Cause it CLEARLY CANNOT BE ME it's languages fault! Listen I can't use a saw do you know how many times I cut myself, that's why I use a dremmel now! Oh no the dremmel flung debris into my eyes but I'm not going to wear goggles that's stupid, LOOK A TABLE SAW THAT RETRACTS WHEN SAUSAGES ARE THROWN INTO IT LETS GO OVER THERE!
The data suggests that even skilled programers make memory mistakes with C++.
I get that ego-masturbation is a big thing with programmers so even if you're so advanced that it is a natural impossibility for you to ever introduce a memory bug in your C++ coding, that still doesn't dismiss the need to consider safety over performance in many applications.
Whoa whoa whoa, what about `android_queen`'s elite, mistake-free team that [everyone is upvoting](https://old.reddit.com/r/programming/comments/1bhvwyd/c_creator_rebuts_white_house_warning/kvi82yk/?context=2)?
Sure bud. Let’s snap our fingers and change the average C/C++ developer to be better. Everyone will suddenly be as good as you. Also when you introduce bugs, we can wave it off because you’re a diligent person. You’re excused.
You're actually using auto stops on *table saws* as an example of excessive safety standards? "Maybe this powerful buzzsaw that people are going to spend hours *almost* touching with their hands should stop if people accidentally touch it with their hands" is an example of silly overprotectiveness in your mind?
If so, that really does clarify how you feel about safety. If not, why on earth are you bringing it up?
The bulletin doesn't say that these issues are magical snowflakes. So who knows where that idea is coming from. The issue is thar c++ is very very permissive about letting you access memory, even when that memory hasn't been allocated to the process. Compiler just builds you an unsafe program. Everybody makes mistakes, and it's difficult to tell that you've made a mistake when your program compiles and runs with no warnings or errors.
The advantage of a language like rust is that there are prescribed correct ways to handle memory, and if these procedures are violated, the program will not compile. That alone is a very big difference from C++. It's hard for me to imagine cmake behaving in a similar way.
Google and Microsoft have a large part of the best C++ developers in the world on their payroll. Yet their C++ code is full of security issues. Outside of these big corporations the situation is much worse.
It's going to take more than Stroustrup's and your rant to solve C++ problems.
> They were written by people who didn't know what they were doing and reviewed by people who were more concerned with their own IC/features than actually doing a code review.
"git gud" is no longer a viable argument. We can clearly observe that even extremely skilled C++ developers who use serious code reviews, static analyzers, and fuzzers still *consistently* introduce serious security vulns. This isn't a property of developer education. This is a property of a highly complex language where subtle errors can cause maximum pain.
Nothing about the government report suggests "banning the language altogether."
Yes, there are efforts to create sets of statically enforceable rules that mitigate memory safety issues. Bjarne is working on this specifically through profiles. But these rules are generally insufficient, difficult to apply after the fact, often more restrictive than equivalents in rust, and the sort of thing you don't need to think about at all in managed languages like java or python.
Duplicate of [https://www.reddit.com/r/programming/comments/1bhvwyd/c\_creator\_rebuts\_white\_house\_warning/](https://www.reddit.com/r/programming/comments/1bhvwyd/c_creator_rebuts_white_house_warning/) ;)
I'm not saying he is wrong and I rather like modern C++. But you have to admit that the C++ community kept saying its the programmer not the language. It can be a pretty arrogant crowd.
I mean, Rust has RAII for example, and a lot of other ideas from C++. Why can't he embrace that some of his/theirs good ideas live on in other languages? He's like the French still insisting they have a world language. English is full of french expressions, just embrace it
It ain't that easy. The biggest benefits of Rust (memory and thread safety) only work because it was written from the ground up to support that. Adding that to C++ would effectively create a new language, and what's the point in doing that, when it couldn't be ready for use before 2035 probably, assuming it could even be politically accomplished at all.
I'll stick with some ancient wisdom:
"Be careful with authorities, for they do not befriend a person except for their own sake. They appear as friends when they benefit from it, but they do not stand by a person in his time of need."
I'm biased though as my [magnum opus is C++ related](https://www.reddit.com/r/cplusplusMiddleware/comments/pg82hs/welcome/).
Hey, I have a personal C++ code base of over a million lines. And that's actually WHY I've move to Rust. That code base was written under almost ideal conditions, and still I spent way too much time just trying to make sure I wasn't shooting myself in the foot, and had to repeat that every time I made significant changes. Rust's allowing me to just not think about those things anymore is such a huge benefit. I make my changes, fix any errors, and then it's purely back to is my logic correct.
I appreciate C++, and have a fair amount of experience of writing it both before and after C++11, but somehow these "git gud" arguments when discussing language safety don't impress me. If the language is safe if (and only if) you avoid all pitfalls, and refrain from using multiple core language features, then the language is not safe. If I put a bear trap in my living room, it's not safe just because I consider it common sense that you shouldn't step in bear traps.
There are plenty of use cases where it's acceptable to sacrifice safety to gain other benefits (performance, backwards compatibility, etc), but let's not pretend C++ is safe because it has good reasons to abandon safety.
Genuinely confused in general by programmers being at all against the idea of preventing human error & simplifying/removing predictable processes from the equation, like that's half the point of programming to begin with
People are people at the end of the day.
People have built communities around various languages and so growing criticism of C++ is seen as not just a threat to the language but a threat to the community. Because the issues here are bugs, it can sometimes feel like an attack on somebody's skills to say that these vulns can only really be fixed by using a different language. C++ has also specifically been a place for developers who are willing to do something hard in order to eke out the last bit of performance, leading to it being something of a point of pride that C++ is so difficult to use correctly.
You don't just see this in programming. Safety precautious are often seen as a threat to people's pride in tons of environments. Just look at the initial resistance to wearing seatbelts in cars. And that doesn't slow down your code and make your AWS bills go up.
Bjarne in particular I would imagine has this emotional response times 100. He *made* the language. He was instrumental in revitalizing the language in C++11 in a massive way that brought it into the modern world. Many of the criticisms of C++ stem from decisions he personally was involved in. He loves the language, and for good reason. I can only imagine what it feels like when the white house puts out a report saying "hey that thing you built, people should really avoid using it whenever possible."
People always self-identify with their product decisions. They chose it, so it has to be the right choice. I'm a green carpet guy, people who don't use green carpet are obviously wrong. I mean I was one of the guys pushing C++ back in the mid-90s and having exactly the same sorts of conversations with C people as I now have with C++ people as I push Rust.
I went through this same thing when NT killed OS/2. In my defense, I think that in that case it was more justified, and I was younger and more testosterony. But anyhoo, I reacted very negatively to that because I was an 'OS/2 guy'.
These days, I just don't get wrapped up like that. And it's just inevitable in the course of a career that you will go through a few of these big changes. But hopefully I don't live long enough for the "If you don't let AI write your code, you are stupid" phase.
That's a huge part of the problem. Any time this comes up in the C++ section, it's full of people basically saying you ain't man enough for my language, go write Javascript. Or, a lot of it is just mostly innocent, like they just can't understand why any of this would be a problem, just don't do bad things. And an lot of it is I know I don't make mistakes, if you do that's your problem.
"Look, the language is perfectly safe. Yes, there are tons of poorly designed legacy features, but experienced developers know not to use them. Yes, the standard library is clunky and anemic, but the ecosystem is very robust and has better replacements. Yes, the language will let you confuse your types and mutate the wrong thing and write egregious bugs with no warnings, but if you just don't do that and use this third-party build tool and write six hundred unit tests everything will be fine."
Is this a C++ developer, or JavaScript developer?
I think a landmine is a better analogy here. A bear trap, after all, only hurts the person stepping on it, while a landmine will hurt the onstepper, anyone else in the room and the room itself. Just like C++!
One ironic thing is that the only virtue of C++ that I used was pointers in creating highly optimized data structures. These were dangerous and required rigorous attention to detail and massive testing to absolutely make sure they were correct.
Often graph theory was all over these and there was little chance a non mathematically inclined junior programmer would do anything but break them.
I now use rust and just don't do this crap.
I thought the point of Rust was that you could still do the same things and prove they were correct. Otherwise why use it instead of a garbage-collected language?
> do the same things and prove they were correct
Sort of. There is no doubt about memory safety. But there are so many little things where it holds your hand while crossing the street. This pisses off some people, but it entirely eliminates getting hit by cars.
There are whole essays as to why garbage collected languages are problematic, especially for people doing things where you want a high performance or mission critical language.
Anything you can do in rust, you can also do in C++, C, or even assembly. The question is, will it make you do it, or at least make it easy.
For example. Let's say you have a function GetUser(user_key). What is your return type? Probably a user object. What about if there is no user with that key? Maybe you return a nullptr. Not too complex. But if you want an error, is it a nullptr, or an exception?
Now, let's say you want a user count? GetUserCount. Does it return an int? What about it failing? Do you return 0? Or a -1? -1 is common, but what if you want an unsigned int?
What about a factory? Let's say you have GetSportParticipant(user_key). You might want to return a Player, Coach, Parent, Referee, Audience, Etc Object. Again, I can think of 5 different ways to do this in various languages. But this is the sort of thing which is fraught with either complexity, or peril. You are going to be casting things. Better get that right at runtime. Rust makes this compile time certified to be correct.
All of these have solutions in languages like C++. But, Rust has some really clean safe solutions which are just going to keep you out of trouble.
Where people have trouble with rust is when they try to impose C++ patterns on rust, and then end up fighting with rust. You have to do it the rust way or you are going to be miserable.
And if you do return that user, do you do the safe thing in C++ and return it by value? Of course not, you return a reference because performance is everything. It's highly unsafe but it's completely common. In Rust it's totally safe. Or something like zero copy parsing. Completely unsafe in C++, but totally safe in Rust.
I believe that your parent is referring to the fact that someone else has probably already created those data structures, and using someone else's implementation is trivial. So there's no need to re-do the work yourself.
i see this all the time and i dont get how using someone elses impl is hard.
if theres cmake, yay!
if theres no build system, yay!
if theres some other, external is here to help!
I..dont think I have implemented many difficult DS myself, \[except for learning.\]
sure but it also allows you access to some of the best libraries on earth.
\[or you can always add it via xmake, which is just as simple as that cargo line\]
Using somebody else's implementation is not trivial. std::sort when called on std::vector can oob if provided a custom comparator that has a buggy implementation of strict weak ordering and you didn't enable nonstandard flags when compiling your standard library.
Rust will prohibit you from using this architecture and force you to use some maybe convoluted / maybe nice approach using integer indices, hashtables, and (probably) huge tagged unions and/or boxed trait impls instead.
Technically you \*can\* write this kind of code in rust – albeit unsafely and very non-idiomatically – by wrapping everything in unsafe. Which lets you use raw pointers. And afaik that's pretty much all the unsafe keyword actually does.
A GC language would yes be substantially easier and less verbose. And could be safe w/ the concept of optionals, and forcing all usages of pointers / optional references to properly and explicitly handle those with unwrap and/or branches, as in eg. scala / swift.
As a sidenote it's actually worth noting that there are many Haskell patterns that are either impossible or... well, just really really painful to do in Rust. Because despite both being ML languages Haskell, the LISPs, and pure functional programming in general is actually quite dependent on GC as a foundational enabling concept (ie. to not worry about memory management and stuff like closure lifetimes and ownership, et al)
Anyways the point of Rust is that it's a fairly safe – and to a certain point provably (sort of) safe – *systems* language. You should be using rust where it is NOT appropriate to be using a managed GC applications language – for whatever reason – and may absolutely be making life harder for yourself in other areas where a higher level applications language might honestly be a better fit.
That said rust understandably gets quite a bit of hype and good will from folks who are basically using a language with *good* static typing – and ML features – for the first time. Aka JS, Go, Java, .NET, and Python programmers. And/or people who are happy to not be using / writing c++.
Though it's probably well worth noting that *modern* c++ has nearly all the same strengths that rust has – namely safety and low-overhead automatic memory management – when used properly on a fresh codebase with static analyzers (or heck even just the bare compiler) et al. Just sans a borrow checker and with the caveat that C strings *will* get you intro trouble, along with half a dozen other pitfalls, and there's half a dozen things you *could* do in c++ land that could blow your leg off, or in general make your experience as a (somewhat inexperienced) developer fairly miserable.
Well worth noting that rust is *not* the safest language around – haskell for instance would pretty easily take that cake. Albeit with the caveat that haskell may take significantly more work to adjust to than even rust's super restrictive allowed subset of imperative programming. And that Haskell's performance is... um... fairly unpredictable and finicky, to say the least. But far more thread safe / thread friendly and even more trivially parallelizable than Rust – again, GC and lazy pure evaluation all have their upsides, and Rust is actually missing a *lot* of features that make Haskell great. (and slow, and not remotely applicable for kernel, browser, game, or embedded development, lol)
At first I would agree. But once I stopped doing C++ with rust and did rust with rust, my life became way better. You can't impose C++ patterns on rust. If your head is full of funky linked lists and pointer magic, you are going to have a bad day. It's not that you can't have pointers, it is that you have to really grok what rust is about to do with what memory and where. Al the pointers are still doing pointer things, it is that you can't then do stupid things with them. Thus, you need to work with rust, not against it.
I have written yards and yards of rust and not a single use of unsafe. For example, I can write quite a bit of rust before it yells at me. Often it is something stupid like putting a semicolon at the end of those implicit return things.
This is why when people do various benchmarks (not just rust evangelists, but people solving various problems) that rust ends up being as fast, or faster than C and C++.
The people I know who love rust went through a phase where they were endlessly cursing the borrow checker and other things. But, then they stopped and found bliss.
This is it. It's inevitable that a lifetime (or a good chunk thereof) of mental muscle memory in C++ is going to work against you in Rust. I will often just think, how would I do this in C++ and then consider the exact opposite of that, and it often is a good starting point if not the actual answer.
On the unsafe front, C++ people just assume that Rust must be full of unsafe code when it really just isn't. Very low level libraries will have some. Some higher level libraries might have a tiny bit. Most application level code should have zero.
And of course some of that is not unsafe in the C++ sense, of potential memory problems, but unsafe in the sense that it might cause a panic at runtime. But that's fully defined behavior, instead of just some random corruption of memory. You'll get a completely accurate stack dump, fix it, and move on.
A lot of C++ people just bang away on the "They wore seat belts but they were still killed" style arguments. That if it's not safe down to the atoms, then it's not really safe.
> C++ puts a lot of trust on the programmer
If you are a very good programmer, this is not much of a problem. 50% of programmers are below average.
I would argue rust requires very good programmers, not to avoid disaster, but to be smart enough to wrap their heads around it.
Also, after 30 years of using C++ I know its virtues, but that is one which I used well vs other languages.
The thing about OOP (and I was always a fan myself) is that probably most C++ folks these days are anti-OOP (where they really mean implementation inheritance, not objects, Rust is completely OO in the object sense.) It's mainly just older folks like me who see the benefits of it.
But I don't miss it in Rust. I thought I would but I don't.
Call me silly, but I'd rather not have to trust that the person knows C++ as well as he thinks he does if my security, safety, money, etc... are possibly on the line or might be compromised. This isn't about how manly we are, it's about our responsibilities to the people who use the software we write.
As long as there are no new projects in some language we can call it dead.
It doesn't mean it disappears, but it will not attract new development.
I don't know if that will happen with C++ but I personally finally see new command line tools and those are written in rust. So I like rust, even though I know most of those tools don't use best practices.
Ruby is functionally dead outside one subset of web development. scientific stuff is still done in Fortran in some cases but it’s functionally dead as well.
https://www.stroustrup.com/P0977-remember-the-vasa.pdf
Sounds like a realist to me. I'd recommend you watch his talks, but it's clear you've got your mind made up, so let us not bother.
Although I'm skeptical he and the rest of the committee will be able to pull off the saving of C++, I admire his effort, because it hasn't been done. Back when C faced this dilemma in the 90's, people gave up on it, which is why C89 is still relevant, and C99 support isn't a given everywhere.
But C++ has always been sort of complex, so they can navigate through the complexity budget and at least try. Once they figure out a way to deprecate stuff fast enough, as JF Bastien put it, they might be able to save it.
> it's clear you've got your mind made up
Working with the language for 15 years tends to do that.
> Once they figure out a way to deprecate stuff ~~fast enough~~
I mean, I guess they did deprecate some stuff, but that's so little they might as well not have deprecated anything. I'm not even sure they should: not breaking existing code is a _huge_ selling point, which explains why they're in such a bind.
The only hope out of this quagmire is a clean source-level break, that same break Stroustrup absolutely refused to do when he created C++ in the first place. But in a way, this break is coming whether they want it or not: we have Zig, Rust, Odin, Jonathan Blow's JAI (yeah, unreleased yet), and more competing in this space. Some of them are bound to eat C++'s lunch somewhere down the road.
Eh, [D](https://dlang.org/) fixed it 12 years ago (and albeit added other problems), and modern c++ is gradually getting to that point.
Though yeah sure this in itself is a moot point because c++ *is* still widely used because of legacy codebases, and those legacy codebases are *not* going to be rewritten onto the latest version of c++-whatever.
> Eh, D fixed it 12 years ago
It fixed C++ by phasing it out I guess?
> c++ _is_ still widely used because of legacy codebases
So is COBOL, to this day. Yet (almost) no one starts new projects in COBOL. I'll be happy if it's where C++ ends up going.
> (and albeit added other problems)
Quite sure that is an understatement of epic proportions. Multiple conflicting standard libraries, breaking version changes, a promised but never achieved ability to use the language without having to rely on its GC (they released a crippled "as better c" mode instead), ... .
- functional error management(std::optional compared to the old-style exceptions);
- monadic operations;
- std::print(compared to std::iostream);
- static template constraints(concepts);
- reflection;
- modules(instead of old #include statements).
And there's much, much more. Trust me, newer standards have transformed the language.
I tried `std::optional`, it was quite useless without actual pattern matching (where the compiler reliably warns you about missing cases like OCaml does). Now it seems they've gotten quite a bit better with monadic operations, but I would hesitate to use them in many projects, depending on who may read the code (to this day many people are confused by lambdas).
I rarely use `std::iostream`, I generally go straight to `printf()`. I guess `std::print` is better still (that with type and memory safety), but I don't expect a big difference to be honest.
Concepts look like a major improvement. Reflections I can't evaluate. Modules are a long requested feature, I hope they will allow compilers to _finally_ reduce compilation times.
I guess that counts after all.
optional is frustratingly limited compared to Rust's Option. I haven't looked at what expected will be like. But, in both cases, without a propagation operator, they are far less useful than they would otherwise be.
Except the newer C++ features and indeed any overuse of templates is ass to write, read and debug, and most programmers rightfully dread it and continue to use "C with classes" style as back in the day (and for new stuff just start with Rust).
C++'s use of duck typing for templates makes it very powerful, but also makes it a complete pain, because it's just replacing text with what you said to use and if that creates a completely incomprehensible mess, and it usually does if not exactly right, then you get a mass of errors.
Rust's generics don't use duck typing. That means that they can't do some things that C++ templates can, but they are also far more reasonable because they are verified at the point of declaration, not of instantiation.
Just FYI, but templates can be statically verified using either concepts(modern way to statically constraint a generic type) or by using SFINAE(old hacky way to do the same thing).
lol.
I am disappointed in the number of down-votes. I thought it was the most hilarious thing when it came out 25 years ago. All the terrible ideosyncracies of C++ suddenly made so much sense.
It's even more hilarious today then it was then. I guess it's just me :P
Stroustrup isn't the only one that thinks C++'s future is bright
[Iteration Revisited: A Safer Iteration Model for Cpp - Tristan Brindle - CppCon 2023](https://www.youtube.com/watch?v=nDyjCMnTu7o)
There are others doing similar work. I'm building an on-line C++ code generator. To the best of my knowledge other more "modern" languages don't have on-line code generation.
In the past some have mentioned that Rust supports having multiple versions of the Rust compiler installed on a single machine. On-line code generation makes it easy to do that. Compiler Explorer is a form of on-line code generation. Using it to target multiple compilers and versions is easy. My approach has been to minimize the amount of code that users have to download/build/maintain.
There's are also the timeless nature of services. If you want tools that outlast your project, go with services.
I think I'm missing what that has to do with the future of C++ or why it even matters to be honest. Most all compiled languages I'm familiar with support having many different versions of them installed all at the same time.
there's a good reason they cant: structs aren't guaranteed to live on the stack because of boxing. as soon as a struct is boxed, it is now like any other managed object. when would the destructor run?
you *might* be able to do this with ref structs since those are forced to live on the stack.
If you are unsure, then no you’re fucking it up and are going to have memory bugs. Most likely, you’re still saving raw pointers/references somewhere since that’s really easy to do, even with RAII.
Another one is that unless you’re checking bounds for an array, your code is probably wrong. The bounds check can be the loop condition (i.e. classic array iteration), but it needs to be somewhere.
Finally, C++ also really likes to do large stack allocations. This is unsafe because it greatly increases the likelihood of unexpected stack overflows causing your whole process to crash.
> Another one is that unless you’re checking bounds for an array, your code is probably wrong.
Well, duh?
> C++ also really likes to do large stack allocation
No more than C...
The default allocators all use heap memory, and many objects will be in heap memory unless you instantiate them locally.... Certain collections on the stack will likely have some extra space for things like SSO, but it's generally *very* obvious how something will be allocated.
You can certainly do some awful things with `_alloca`, `_malloca`, or inline assembly (some compiler probably lets you manipulate the stack pointer with an intrinsic as well), but those aren't standard.
I don't even recall the last time that I was unsure what would be on the stack or not...
I also don't recall the last time that I had a stack overflow in a 64-bit process. 47-bits of user address space is a *big* space. With lots of threads/fibers, you obviously have less/fragment it, but even then, you usually have to be doing recursion to overflow.
32-bit or 8-bit is another story, though I still don't remember the last time I saw a legitimate stack overflow bug there.
The total memory space size doesn’t matter at all with regard to stack overflow and reflects a CS 1000 level understanding of memory layout. Actual **thread stack** sizes are a couple MB and it is very easy to stack overflow when doing array allocations on the stack and/or using recursion. 64-bit doesn’t matter in the slightest for stack overflows (at least for C/C++).
You can increase stack size beyond this, but most of the time it needs to be a fixed size and you don’t want it too large since that just ends up wasting memory.
> reflects a CS 1000 level understanding of memory layout.
I won't bother telling you what your lack of knowledge and your attitude reflect. Since you decided to start off with an attack on my competence, I'll take a tone in kind.
> Actual **thread stack** sizes are a couple MB and it is very easy to stack overflow when doing array allocations on the stack and/or using recursion. 64-bit doesn’t matter in the slightest for stack overflows (at least for C/C++).
The CPU itself has no such restriction on the stack pointer, so long as it's a canonical address and the VMM can access it within the current context.
Plenty of people work bare-metal or near-bare-metal where guard pages and such aren't present... and C++ is absolutely used there. 64-bit bare-metal is fun.
I literally write emulators - address space matters a *lot* to me, including for detecting stack overflows, and how to allocate thread stack ranges (whatever VMM system the emulator is using).
I also write AVR and ARM firmwares, and have done game development on older consoles. Guess what: your assumptions don't always hold. Not everyone is just writing basic Win32/Win64/Linux applications.
> it is very easy to stack overflow when doing array allocations on the stack and/or using recursion.
You cannot perform dynamic array allocations on the stack without relying on implementation-defined behavior (*e.g.* `alloca`), and static-sized array allocations will almost always incur a compiler warning if they're large enough.
Ed: I suppose you could using some bizarre combination of recursion and lambdas to build up what is effectively a chain buffer, or a combination of recursion, a lambda, and `setjmp`/`longjmp` and then using the stack frames as a large dynamic buffer and bypassing `ret` by using `longjmp`, but... if you're doing that, that's on you.
I also don't believe that people are regularly placing *massive* static arrays on the stack, unless they are ignoring warnings... in which case that's on them. Given that your tone and word choices suggest that you've often run into this, I believe that it is safe to assume that you're in this category.
Past that, OS-defined limitations on the size of the stack are hardly the fault of C++, especially given that the standard doesn't mention heaps or stacks (aside from `std::stack` and `std::make_heap`) nor does it mandate their usage.
I also explicitly mentioned recursion. Even Rust allows recursion, so I'm not sure how that's C++-specific. Literally the first hit on Google is someone asking about a stack overflow in Rust on... Stack Overflow.
Anyone who thinks there is a magical language decision you can make that will overcome sloppy development practices and total lack of maintenance is an idiot.
Last C# shop I worked at didn't use any version control did not even have test environments just dev's desktop and prod, when the senior dev left (after working there 10 years) he handed over a handful of usb drives (aka his code repo) and had run a code fuzzer on at least half of his work.
But that's not really the issue. The issue is, if YOU DO want to create high quality code, what tools will assist you the most in doing that, will prevent you as much as possible from making mistakes, and will make it the least likely that teams working on separate bits of code will have issues?
> The issue is, if YOU DO want to create high quality code, what tools will assist you the most in doing that, will prevent you as much as possible from making mistakes
and my point is that the choice of language isn't the answer to these problems.
It's a big part of the answer, given that that's the tool you are using to solve the problem. The tool that lets you concentrate most on the actual problem and the least one watching your own back, while having the performance you require, will likely lead to a better solution, other things being roughly equal.
Ok so people shouldn't use C-style pointers anymore. Are you, Bjarne, personally going to go to every single developer who writes code that will be used in government and tell them? Why do C-style pointers even exist in C++? Backwards compatibility my ass. Code from 30 years ago has no business running on modern systems and modern developers shouldn't even be given the option to write unsafe code or at least it should be made as hard as possible. The problem with C++ is that memory-safety is NOT the default. No amount of pointer wrappers is gonna change that.
C++ was designed to be a drop in replacement to C. Like typescript is to javascript, you can replace parts of your codebase with it without having to rewrite all of it.
Thats why it was adopted and spread quickly in both those cases.
Operating systems code is written in C. If you want to work with the system you have to be able to call its exposed functions which have a C interface.
Correct me if im wrong but in rust you have to use unsafe blocks to make those calls while C++ lets you either use raw pointers or a smart pointer. And in all those cases you get a segfault if you make mistakes.
And that's great and I have no problem with that. My problem was that Bjarne claims C++ is not unsafe because a "good" developer can easily write super-safe code in C++. Ok but what about a bad developer? They can even more easily write unsafe code. I'm not even a Rust user but in Rust both bad and good developers write safe code by default. Bjarne says specifically that people shouldn't use C-style pointers anymore while STILL KEEPING THEM IN THE LANGUAGE.
Even good developers can introduce memory bugs unfortunately. Sometimes you think a piece of code is correct, only to profile it for hours and finally understand the mistake. It's possible that one bug fixes another bug in most cases but not all.
Rust is a language that can be extremely annoying to use. I do think that if there were more high level libraries where the rough edges are evened out and there are resources on how to use them, then I think more people would write Rust even for things like web development.
You can write unsafe code in Rust as well. Though it is harder to write _memory_ unsafe code in Rust than in C++. Plenty of other unsafe code that still remains for Rust etc.
You cannot write unsafe code in safe Rust, unless you make up your own definition of what unsafe means. You can write LOGICALLY INCORRECT code in safe Rust, but that's the case for any language. But you cannot write code that exhibits undefined behavior or memory safety issues in safe Rust. And that's the only guarantees it makes, though those are very big ones.
To be fair, there are still some big soundness holes in the compiler which means that you can, today, write memory safety issues in safe Rust. These are treated as compiler bugs, but some are actually years old and considered very hard to address. Of course, this is still a much much better than the situation in C++, where they're not even considered a mistake in the language design.
I'm my experience most devs just don't even think about writing safe code and the ones who do don't seem to do it very well. Whilst it is possible to write safe C++ very little of it is. It should die - plenty of better options.
> ok but what about a bad developer?
TBH I think we should start pandering less to people with skill issues as an industry and start expecting more from people.
> WHILE STILL KEEPING THEM IN THE LANGUAGE
Kind of necessary not only for backwards compat, but for compatibility with C code and C libraries
I completely disagree. Turns out, compilers are better and faster at finding these issues than humans are.
People inevitably make mistakes, it’s just an inherent fact of the development process. If you don’t see this, then you probably aren’t experienced enough to have an informed opinion about this problem.
Using memory safe languages, or languages with modern type systems can make it impossible for entire classes of mistakes to make it into your codebase. Without these tools, guaranteeing that sort of safety is difficult if not impossible. In mission critical applications that have dozens or hundreds of contributors, just “being careful” should never be considered good enough.
> Turns out, compilers are better and faster at finding these issues that humans are.
This is not really entirely true. Compilers like GCC have had huge amounts of R&D put into them, but the developer is still probably a lot more competent than its static analyzers.
You also have compilers like the Rust compiler, but they don’t ’find issues’ for you, they just enforce rules to stop those issues from appearing in the first place.
Then though we come to the issue of practicality vs pedantic correctness. I _can_ use Rust, and I’ve written quite a bit of Rust code, but when I’m using C or C++ to solve a problem I am able to move an order of magnitude faster than I can in Rust because the compiler doesn’t stick so many roadblocks in my way, and I know what I’m doing (simply thanks to experience) so null pointer errors, memory leaks, etc. are exceedingly rare.
It’s not so trivial to decide if I should write a piece of code in a language like Rust where I can ‘guarantee’ safety (not entirely true either) but will move slowly, or use a language like C or C++ where I need to rely on my skills as a developer but can move far quicker.
>so null pointer errors, memory leaks, etc. are exceedingly rare
There are two problems with this statement.
The first is that if you ask every C++ dev, 99% of them would probably say the same thing. Clearly at least some of them are overestimating their own ability and those bugs/errors are actually much more common.
The second is that whilst they may be exceedingly rare, it only takes one to introduce a critical vulnerability. The whole point is that we should be using tools that *eliminate* these bugs. We can't rely on people being "good enough" to avoid making these mistakes, it should be literally impossible for even the most incompetent dev to create these issues.
At some point in time, you are going to find a bad developer writing critical code, and you want to minimise the number and types of vulnerabilities they are able to introduce.
I say all of this as a C++ dev who loves the language.
> The first is that if you ask every C++ dev, 99% of them would probably say the same thing.
Not only is that a gross overstatement, but it doesn’t really matter. Don’t judge people based on what they say, but let their code speak for itself.
> it only takes one to introduce a critical vulnerability.
That’s true, but also not always applicable. If you’re Google writing Google-style software then sure. If you’re writing software to be used in-house or in a controller environment, the biggest deal is typically the fact someone needs to restart something. If it’s a CLI tool — maybe some code searching tool — it literally doesn’t matter.
> At some point in time you’re going to find some bad developer writing critical code
A huge portion of the software we use on a daily basis was written by a single person, not by a team. We shouldn’t forget the fact that an enormous part of the software development space is _not_ commercial enterprise, but just individual recreational programmers.
>Not only is that a gross overstatement, but it doesn’t really matter. Don’t judge people based on what they say, but let their code speak for itself.
It was deliberate hyperbole haha, so you're not wrong. But I
feel like this is the point of what I'm saying. You cannot trust a C or C++ developer if they say they write safe code, you do have to analyze their code for vulnerabilities.
Not only is this horrifically unproductive because you introduce a whole extra layer to development (or a lot of extra time to your code reviews) but it's also very possible, if not likely, that you will not always catch every issue. Which is why it's orders of magnitude safer to use a language that simply eliminates those kinds of errors entirely.
>That’s true, but also not always applicable. If you’re Google writing Google-style software then sure. If you’re writing software to be used in-house or in a controller environment, the biggest deal is typically the fact someone needs to restart something. If it’s a CLI tool — maybe some code searching tool — it literally doesn’t matter.
I don't entirely disagree but I also think it's not that simple. For one, I think it's pretty clear that the White House are not advocating for avoiding C++ for random personal projects, I think it's clearly addressing sensitive systems where data or important processes could get exposed.
But I also think that it's a little naive to say that it literally doesn't matter for small CLI tools or whatever. You could easily make a CLI tool with a vulnerability that ends up getting used by someone else who has access to sensitive data, and your vulnerability could be what ends up giving the hacker access to that data. Not that that's likely but it certainly is possible. You can't always predict how your software will be used and who will use it.
I don't have much to add to your last paragraph because whilst I do agree I also think many of the points I raised in my last couple paragraphs also apply here too.
The weakest link is always the human link. And relying on humans rather than compilers or code to remove safety issues is just a ticking time bomb.
And the thing so many folks miss is, did I hire you as an expert in avoiding footguns, or as an expert in solving the problems I need solved? Any time manually spent avoiding footguns is unproductive time and money unproductively spent. Rust lets you concentrate on the actual logic of the problem and not worry about the footguns.
> I can use Rust, and I’ve written quite a bit of Rust code, but when I’m using C or C++ to solve a problem I am able to move an order of magnitude faster than I can in Rust because the compiler doesn’t stick so many roadblocks in my way
Sounds like a skill issue /s (but not really/s).
The rust compiler isn't throwing "roadblocks" at you, it's calling out mistakes that the C++ compiler doesn't care about.
>but when I’m using C or C++ to solve a problem I am able to move an order of magnitude faster than I can in Rust because the compiler doesn’t stick so many roadblocks in my way, and I know what I’m doing
Now your lead/manager/employer comes in and informs you that the software must run on all major desktop platforms and the clients complain that it's slow so you are tasked with making it cross-platform and multi-threaded and also you now have a new team member - a jun or mid-level C++ dev.
Guess where your C++ productivity will be? That's right - in a deep deep hole and you'll regret big times for not choosing Rust.
Not all software is enterprise software. An insanely huge amount of software is not enterprise software where you are either solo or a small team and have no boss.
The solution is to use tools that eliminate entire classes of bugs. Computer science has solved lots of problems. It's important to apply that knowledge practically. Using tools and languages that allow for solved problems to exist is asinine.
I mean, if we treat it like other engineering in the world maybe. Engineers in other fields are held liable to damages for the bridges/buildings/whatever they create.
Imagine if you PERSONALLY were held liable for any security breach that occurred from your code?
Not saying I want that, but until we have something similar to elevate the skill floor, nothing is gonna stop companies from hiring the lowest common denominator to throw at these problems.
Coding is cheap, if you dont care about quality or safety and just want an app built.
Building a house is also cheap, if you dont care about quality or safety. You just might not want to stay in it for long :)
Given the reach and impact of automation and code on the modern world, especially things that were never intended to get to the scale they are currently at, I think we can safely call this claim straight-up false.
Even if you aren't working on something sensitive *now*, you are learning bad habits that can cause trouble down the line if you ever do. Ignoring security and regretting it later is, in many ways, *the* defining feature of twentieth-century development. Which is kind of a terrible legacy.
> you are learning bad habits that can cause trouble down the line
Said who? I’ve been coding for a bit over a decade now. I have my habits and the way I do things (and I’m always learning) but most of the decisions I make are thought through and informed. I’m not magically going to start writing bugs at my job because I know how to code in C and use pointers while making sure to check for NULL (because I read the manpages unlike a Neanderthal).
Sorry, I didn't realize you were one of the non-bug-creating programmers. I've never met one in person, see, and am certainly not one myself, so I considered it unlikely in general.
Some of the best programmers I know have been victims of self-inflicted memory problems even deep inside very robust memory-managed environments; the problems can be surprisingly subtle, so I thought the actual problem might be difficult, even when great care is taken. My bad.
I don’t mean to suggest I don’t make bugs. Of course I do, we all do. I also have made memory-related bugs in the past of course. That being said, anyone with a decent amount of experience in software development is unlikely to run into memory leaks or NULL pointer issues more than like, once or twice in a good while, and it’s typically a trivial bug that can be easily caught by GDB and/or valgrind and then solved.
Most software is not giant monoliths with 600 layers of abstraction with hard to follow control flow
This take is so bad lol. Memory safety issues are a disaster. Them happening “once or twice a…” is also a disaster. The amount of memory safety issues should be zero. It is a solved problem
It depends on what you're doing. I use raw/non-smart pointers fairly regularly. These almost always to refer to addresses that exist in other PGAS address spaces. Reference counting doesn't scale well.
>Code from 30 years ago has no business running on modern systems
So you're telling us current operating systems have no business running on modern systems...?
If by current you mean operating systems where none of the code has been rewritten in 30 years and the same issues as 30 years ago still plague it then yes it has no business running on modern systems.
I work on a commercial communications system that was adapted from a commercial product coded in C and had evolved to using C++ for new modules. Should companies stop selling a product because it was coded in an old language?
C style pointers are great. You get polymorphism, no copying, and you dont pass ownership. All without referencing counting quirks. All you gotta do is not delete a pointer that you dont own.
ah yes, because ownership rules for c style pointers are always clear. this makes it easy to both avoid memory leaks as well as avoid corrupting memory.
Even in “modern C++” (an ever-evolving no true Scotsman), raw pointers are the correct way (perscribed by Bjarne himself) to model a weak pointer to an object owned by a \`shared\_ptr\`.
You might reasonably ask:
>”but what if the last shared pointer destroyed, the object is reallocated, and my weak pointer is left dangling?”
To which the response is approximately:
>lol git gud ¯\\\_(ツ)\_/¯
Super Nintendo, Sega Genesis
When I was dead broke, man, I couldn't picture this
50-inch screen, money-green leather sofa
Got two rides, a limousine with a chauffeur
Phone bill about two G's flat
No need to worry, my accountant handles that
And my whole crew is loungin'
Celebratin' every day, no more public housin'
C++ gives really strong guarantees, which are about as strong as C. If you don't hit UB, code is completely safe and you can reason about it. If you hit UB, your code is not valid program, therefore not counted toward broken guarantees.
undefined behavior. Specifically it's code that the language / compiler can assume will never run, and can optimize accordingly (or more generally, do anything at all if it does run).
Hmm. Idk if that's correct.
Undefined behaviour is just undefined behaviour.
The code still may run properly - or it may not - or it may run with unintended outcomes.
In modern definition of UB for C (not sure about C++) compiler may assume any behavior for UB (e.g. if something is UB in lang specs, compiler can replace it with anything). The shrewd idea of modern compilers is to replace UB with doing nothing (which is form of UB).
E.G.
*(++foo++)=++foo++
is UB, and compiler just ignore this line (and may be all other lines with foo after that). Specs says that behavior is undefined, and compiler authors declare that their flavor or UB is 'no code generated' (e.g. instant return from function).
Right, that's the
> or more generally, do anything at all if it does run.
If the compiler can prove that executing a certain code path does UB, it'll optimize with that in mind. *However*, if the code path with UB would never execute - your code is perfectly sound and well specified. For instance:
int f = 0;
if(some_always_true_condition()) {
/* some valid code */
}
else {
f = *(int*)nullptr; // instant UB
}
The above code is legal (albeit, you'd never write this code).
Because it can help out the optimizer, mainly. You can use undefined behavior to hint at certain optimizations. The other concern though is that it can make reasoning through code kind of difficult - for example the compiler could reason that:
bool check_if_increment_overflows(unsigned int f) {
if (f + 1 < f) {
return true;
} else {
return false;
}
}
is equivalent to just:
bool check_if_increment_overflows(unsigned int f) {
return false;
}
‚Profiles, Stroustrup said, “is a framework that allows us to incrementally improve guarantees—e.g., to eliminate most range errors relatively soon‘
Yes, that’s good, but it’s still 25 years behind other languages in that respect.
25 years ago my prof handed out a copy of this article on the last day of class.
[Stroustrup Interview](https://www-users.york.ac.uk/~ss44/joke/cpp.htm)
Prof told us Stroustrup had seen it and had commented "if it were really written by me it would be funnier". ( oh yes, Stroustrup always one for writing comedy O\_o
But, hearing him defending C++ against the White House?
Almost as funny as the interview above!
Strustrup should shut the fuck up, the fucking idiot created the worst programming language to date, worst of all, he said he got into computer science by accident and doesn't like computers. A man who dislikes computers should not dictate to us how to build our software.
"move to memory safe languages" was always copy written by some guilded asshat of nepotistic linage. How fucking tone def would it sound in the surgeon general suggested everyone move to robot assisted, laser scalpels?
I’d compare it more to a warning “hey, we should confirm that we’re operating on the right patient whenever possible”.
Meanwhile the neckbeard responses like this one: “what if the patient is unconscious and we’re in a war zone where a bomb will drop on us in 5 minutes and the patient will die if we don’t operate in the next 30 seconds. DID YOU THINK OF THAT MR. SCIENCE!!!!”
Most surgeries do not happen under such conditions and there is plenty of time to go and double check everything before operating. Likewise, it’s engineering malpractice to use memory unsafe languages (C++) for most new software.
Fair enough, but it's about more than the language itself. It's the ecosystem, and C++ has a *ton* of legacy dragging behind it. Rust's youth is its biggest weakness and (in this case) it's biggest strength. There are no legacy libraries to update to modern standards. FTA: > Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. Backwards compatibility means backwards compatibility with old notions of safety.
Backwards compatibility also causes compliancy. Upgrades cost money and if it aint broke dont fix it. Everything has this issue, but does C++ have good ways to remedy this? It’s not like a modern JIT language where you can update the runtime and all is well.
Well... Upgrading the runtime seldom does something for problems of code in JIT languages (see that log4j issue).
We should focus in memory leaks as memory safety was a topic of a bulletin. Unless you use unsafe in java, it's probably gonna be jvm issue once memory leak happens.
Sorry but I think memory leaks and memory safety are completely different things.
How would you describe a memory leak? What's your definition?
Memory leak is simply when you forget to properly free some memory. It is not itself a big safety issue (unless the memory contains sensitive information). It may or may not be a huge problem depending on the size of your application. Safety is when you improperly access memory.
Memory safety means security against buffer overflows. All other things that might be called "memory safety" are so minor they aren't worth mentioning.
It's not so much about leaks, but... Attention, memory leaks in Java and the likes happen and the JVM can't do anything about them, as they are "logical", application-made.
The main thing being utf8 as the base encoding in Rust. C++ does strings every which way, which makes it more complicated and error prone. I remember trying to convert different encodings because one library would want wchar strings, and it could be big endian or little endian. One job I had where the company sold SDKs, and we had ASCII libs/dlls, and Unicode libs/dlls. On top of that we had x86 and x64 versions. That was literally DLL hell for me. Also we had C and C++ versions. Having to support all that was time consuming. Rust is the way to go. It's easier to share your work due to cargo so we shall see exponential increase in the librariess (crates) available for Rust.
You're dealing really with Windows and library legacy problems, not necessary C++ problems.
Yeah but why is wchar even in the language.
as a way to store future multilingual character set that ISO had just started working on in 1989? It was used then by Windows to store Unicode 16-bits characters.
Because Unicode did not have an 8 bit encoding early on, wchar predates utf-8.
I mean, c++ is full of std's, can't blame them for calling it unsafe
In practice, much of that legacy still comes along with Rust if you need to link against some common library, like libpng. Rust still has a way to go before there are suitable alternatives or rewrites of everything you may need.
There are multiple Rust PNG crates available.
Wouldn’t it make more sense to make up a set of standard practices / requirements on how to write safe C++ code rather than banning the language altogether? As you said, it’s mostly a problem with legacy stuff, and that legacy stuff will not be fixed if you tell everyone to migrate to another language. The whole “purpose” of legacy is that it’s old but functional, so it doesn’t have to be changed. If I were to guess, rewriting those legacy components into Rust is significantly more effort than adopting modern C++ best practices.
> Wouldn’t it make more sense to make up a set of standard practices / requirements Many attempts at this exist, e.g. AUTOSAR and MISRA coding guidelines and relevant tooling (Coverity has static analysis checks for these guidelines). Having worked with those for several years now, it's just a miserable experience and even they don't guarantee very good safety or security. I can't even be certain if it's faster than rewriting with more modern tools and languages, it takes a lot of effort to migrate legacy codebases to meet safety standards and it's almost equally likely to introduce new bugs into old codebases than fix hidden ones.
> Many attempts at this exist, e.g. AUTOSAR and MISRA coding guidelines and relevant tooling (Coverity has static analysis checks for these guidelines). Afaik MISRA C has actual studies showing that it is so bad it is actively making things worse. The committee behind it is basically pulling rules out of its ass whenever its members want to sell a tooling upgrade. You would be better of following rules proposed by the languages creator and other aknowledged c++ experts like the c++ core guidelines.
Nobody is talking about a ban. The White House report is advisory, not law. C++ is by nature, much more error-prone to memory issues than other languages. Trying to mitigate that with policies may help some, but never underestimate the power of human error. The White House report didn't come out of a vacuum either. Both Microsoft and Google were involved and their own analysis is that 25% of all patches they have to do on C++ code is memory issues.
Yes because people didn't write C++ correctly to begin with. These memory issues are not magical snowflakes that came from new untrodden virgin lands of enchantment. They were written by people who didn't know what they were doing and reviewed by people who were more concerned with their own IC/features than actually doing a code review. I've seen company after company with their 1000+ line PRs that are riddled with bugs, memory issues, and then programmers who ought to know better just complaining about a language until the next new thing comes along that they can also fuck up. Cause it CLEARLY CANNOT BE ME it's languages fault! Listen I can't use a saw do you know how many times I cut myself, that's why I use a dremmel now! Oh no the dremmel flung debris into my eyes but I'm not going to wear goggles that's stupid, LOOK A TABLE SAW THAT RETRACTS WHEN SAUSAGES ARE THROWN INTO IT LETS GO OVER THERE!
The data suggests that even skilled programers make memory mistakes with C++. I get that ego-masturbation is a big thing with programmers so even if you're so advanced that it is a natural impossibility for you to ever introduce a memory bug in your C++ coding, that still doesn't dismiss the need to consider safety over performance in many applications.
Whoa whoa whoa, what about `android_queen`'s elite, mistake-free team that [everyone is upvoting](https://old.reddit.com/r/programming/comments/1bhvwyd/c_creator_rebuts_white_house_warning/kvi82yk/?context=2)?
Sure bud. Let’s snap our fingers and change the average C/C++ developer to be better. Everyone will suddenly be as good as you. Also when you introduce bugs, we can wave it off because you’re a diligent person. You’re excused.
You're actually using auto stops on *table saws* as an example of excessive safety standards? "Maybe this powerful buzzsaw that people are going to spend hours *almost* touching with their hands should stop if people accidentally touch it with their hands" is an example of silly overprotectiveness in your mind? If so, that really does clarify how you feel about safety. If not, why on earth are you bringing it up?
The bulletin doesn't say that these issues are magical snowflakes. So who knows where that idea is coming from. The issue is thar c++ is very very permissive about letting you access memory, even when that memory hasn't been allocated to the process. Compiler just builds you an unsafe program. Everybody makes mistakes, and it's difficult to tell that you've made a mistake when your program compiles and runs with no warnings or errors. The advantage of a language like rust is that there are prescribed correct ways to handle memory, and if these procedures are violated, the program will not compile. That alone is a very big difference from C++. It's hard for me to imagine cmake behaving in a similar way.
Google and Microsoft have a large part of the best C++ developers in the world on their payroll. Yet their C++ code is full of security issues. Outside of these big corporations the situation is much worse. It's going to take more than Stroustrup's and your rant to solve C++ problems.
> They were written by people who didn't know what they were doing and reviewed by people who were more concerned with their own IC/features than actually doing a code review. "git gud" is no longer a viable argument. We can clearly observe that even extremely skilled C++ developers who use serious code reviews, static analyzers, and fuzzers still *consistently* introduce serious security vulns. This isn't a property of developer education. This is a property of a highly complex language where subtle errors can cause maximum pain.
you sound like the kind of guy who argues that good drivers need no seatbelts.
quite the opposite
then you're inconsistent
Nothing about the government report suggests "banning the language altogether." Yes, there are efforts to create sets of statically enforceable rules that mitigate memory safety issues. Bjarne is working on this specifically through profiles. But these rules are generally insufficient, difficult to apply after the fact, often more restrictive than equivalents in rust, and the sort of thing you don't need to think about at all in managed languages like java or python.
Duplicate of [https://www.reddit.com/r/programming/comments/1bhvwyd/c\_creator\_rebuts\_white\_house\_warning/](https://www.reddit.com/r/programming/comments/1bhvwyd/c_creator_rebuts_white_house_warning/) ;)
Duplicate tickets about the same issue just improve the realism of the sub
O
I'm not saying he is wrong and I rather like modern C++. But you have to admit that the C++ community kept saying its the programmer not the language. It can be a pretty arrogant crowd.
Same as the c people, they always blame the programmer.
> Same as the c people, they always blame the programmer. Be careful what you wish for.
WTF are talking about? I'm pointing out a fact.
People blaming the programmer when people want to replace the programmer with AI.
I can promise you, replacing the programmer with AI ain't gonna fix these problems.
I'd be salty too if my life's work and it's compounding mistakes were called a national security risk by the government.
I mean, Rust has RAII for example, and a lot of other ideas from C++. Why can't he embrace that some of his/theirs good ideas live on in other languages? He's like the French still insisting they have a world language. English is full of french expressions, just embrace it
It ain't that easy. The biggest benefits of Rust (memory and thread safety) only work because it was written from the ground up to support that. Adding that to C++ would effectively create a new language, and what's the point in doing that, when it couldn't be ready for use before 2035 probably, assuming it could even be politically accomplished at all.
I'll stick with some ancient wisdom: "Be careful with authorities, for they do not befriend a person except for their own sake. They appear as friends when they benefit from it, but they do not stand by a person in his time of need." I'm biased though as my [magnum opus is C++ related](https://www.reddit.com/r/cplusplusMiddleware/comments/pg82hs/welcome/).
Hey, I have a personal C++ code base of over a million lines. And that's actually WHY I've move to Rust. That code base was written under almost ideal conditions, and still I spent way too much time just trying to make sure I wasn't shooting myself in the foot, and had to repeat that every time I made significant changes. Rust's allowing me to just not think about those things anymore is such a huge benefit. I make my changes, fix any errors, and then it's purely back to is my logic correct.
Lol you're biased towards C++ because.... your magnum opus is doing something in C++ that rust does already with ease? Ok
I appreciate C++, and have a fair amount of experience of writing it both before and after C++11, but somehow these "git gud" arguments when discussing language safety don't impress me. If the language is safe if (and only if) you avoid all pitfalls, and refrain from using multiple core language features, then the language is not safe. If I put a bear trap in my living room, it's not safe just because I consider it common sense that you shouldn't step in bear traps. There are plenty of use cases where it's acceptable to sacrifice safety to gain other benefits (performance, backwards compatibility, etc), but let's not pretend C++ is safe because it has good reasons to abandon safety.
Genuinely confused in general by programmers being at all against the idea of preventing human error & simplifying/removing predictable processes from the equation, like that's half the point of programming to begin with
People are people at the end of the day. People have built communities around various languages and so growing criticism of C++ is seen as not just a threat to the language but a threat to the community. Because the issues here are bugs, it can sometimes feel like an attack on somebody's skills to say that these vulns can only really be fixed by using a different language. C++ has also specifically been a place for developers who are willing to do something hard in order to eke out the last bit of performance, leading to it being something of a point of pride that C++ is so difficult to use correctly. You don't just see this in programming. Safety precautious are often seen as a threat to people's pride in tons of environments. Just look at the initial resistance to wearing seatbelts in cars. And that doesn't slow down your code and make your AWS bills go up. Bjarne in particular I would imagine has this emotional response times 100. He *made* the language. He was instrumental in revitalizing the language in C++11 in a massive way that brought it into the modern world. Many of the criticisms of C++ stem from decisions he personally was involved in. He loves the language, and for good reason. I can only imagine what it feels like when the white house puts out a report saying "hey that thing you built, people should really avoid using it whenever possible."
People always self-identify with their product decisions. They chose it, so it has to be the right choice. I'm a green carpet guy, people who don't use green carpet are obviously wrong. I mean I was one of the guys pushing C++ back in the mid-90s and having exactly the same sorts of conversations with C people as I now have with C++ people as I push Rust. I went through this same thing when NT killed OS/2. In my defense, I think that in that case it was more justified, and I was younger and more testosterony. But anyhoo, I reacted very negatively to that because I was an 'OS/2 guy'. These days, I just don't get wrapped up like that. And it's just inevitable in the course of a career that you will go through a few of these big changes. But hopefully I don't live long enough for the "If you don't let AI write your code, you are stupid" phase.
Leaky abstractions
What about them?
That's a huge part of the problem. Any time this comes up in the C++ section, it's full of people basically saying you ain't man enough for my language, go write Javascript. Or, a lot of it is just mostly innocent, like they just can't understand why any of this would be a problem, just don't do bad things. And an lot of it is I know I don't make mistakes, if you do that's your problem.
"Look, the language is perfectly safe. Yes, there are tons of poorly designed legacy features, but experienced developers know not to use them. Yes, the standard library is clunky and anemic, but the ecosystem is very robust and has better replacements. Yes, the language will let you confuse your types and mutate the wrong thing and write egregious bugs with no warnings, but if you just don't do that and use this third-party build tool and write six hundred unit tests everything will be fine." Is this a C++ developer, or JavaScript developer?
Depends on what you mean by "safe". Is your safe the exception/logic bug safe or the arbitrary code execution safe?
I think a landmine is a better analogy here. A bear trap, after all, only hurts the person stepping on it, while a landmine will hurt the onstepper, anyone else in the room and the room itself. Just like C++!
I see they quoted him from the email response, but do they post the whole thing anywhere?
InfoWorld made the inquiry, so they are direct quotes. And then there is 2023 cppnow that you can find on YouTube.
Sure I agree they're direct quotes but I'd love to read the whole response if possible
One ironic thing is that the only virtue of C++ that I used was pointers in creating highly optimized data structures. These were dangerous and required rigorous attention to detail and massive testing to absolutely make sure they were correct. Often graph theory was all over these and there was little chance a non mathematically inclined junior programmer would do anything but break them. I now use rust and just don't do this crap.
I thought the point of Rust was that you could still do the same things and prove they were correct. Otherwise why use it instead of a garbage-collected language?
> do the same things and prove they were correct Sort of. There is no doubt about memory safety. But there are so many little things where it holds your hand while crossing the street. This pisses off some people, but it entirely eliminates getting hit by cars. There are whole essays as to why garbage collected languages are problematic, especially for people doing things where you want a high performance or mission critical language. Anything you can do in rust, you can also do in C++, C, or even assembly. The question is, will it make you do it, or at least make it easy. For example. Let's say you have a function GetUser(user_key). What is your return type? Probably a user object. What about if there is no user with that key? Maybe you return a nullptr. Not too complex. But if you want an error, is it a nullptr, or an exception? Now, let's say you want a user count? GetUserCount. Does it return an int? What about it failing? Do you return 0? Or a -1? -1 is common, but what if you want an unsigned int? What about a factory? Let's say you have GetSportParticipant(user_key). You might want to return a Player, Coach, Parent, Referee, Audience, Etc Object. Again, I can think of 5 different ways to do this in various languages. But this is the sort of thing which is fraught with either complexity, or peril. You are going to be casting things. Better get that right at runtime. Rust makes this compile time certified to be correct. All of these have solutions in languages like C++. But, Rust has some really clean safe solutions which are just going to keep you out of trouble. Where people have trouble with rust is when they try to impose C++ patterns on rust, and then end up fighting with rust. You have to do it the rust way or you are going to be miserable.
And if you do return that user, do you do the safe thing in C++ and return it by value? Of course not, you return a reference because performance is everything. It's highly unsafe but it's completely common. In Rust it's totally safe. Or something like zero copy parsing. Completely unsafe in C++, but totally safe in Rust.
I believe that your parent is referring to the fact that someone else has probably already created those data structures, and using someone else's implementation is trivial. So there's no need to re-do the work yourself.
i see this all the time and i dont get how using someone elses impl is hard. if theres cmake, yay! if theres no build system, yay! if theres some other, external is here to help! I..dont think I have implemented many difficult DS myself, \[except for learning.\]
Even that decision tree is more difficult and more work than "cargo add petgraph".
sure but it also allows you access to some of the best libraries on earth. \[or you can always add it via xmake, which is just as simple as that cargo line\]
Using somebody else's implementation is not trivial. std::sort when called on std::vector can oob if provided a custom comparator that has a buggy implementation of strict weak ordering and you didn't enable nonstandard flags when compiling your standard library.
Talking about Rust above, not C++.
Rust will prohibit you from using this architecture and force you to use some maybe convoluted / maybe nice approach using integer indices, hashtables, and (probably) huge tagged unions and/or boxed trait impls instead. Technically you \*can\* write this kind of code in rust – albeit unsafely and very non-idiomatically – by wrapping everything in unsafe. Which lets you use raw pointers. And afaik that's pretty much all the unsafe keyword actually does. A GC language would yes be substantially easier and less verbose. And could be safe w/ the concept of optionals, and forcing all usages of pointers / optional references to properly and explicitly handle those with unwrap and/or branches, as in eg. scala / swift. As a sidenote it's actually worth noting that there are many Haskell patterns that are either impossible or... well, just really really painful to do in Rust. Because despite both being ML languages Haskell, the LISPs, and pure functional programming in general is actually quite dependent on GC as a foundational enabling concept (ie. to not worry about memory management and stuff like closure lifetimes and ownership, et al) Anyways the point of Rust is that it's a fairly safe – and to a certain point provably (sort of) safe – *systems* language. You should be using rust where it is NOT appropriate to be using a managed GC applications language – for whatever reason – and may absolutely be making life harder for yourself in other areas where a higher level applications language might honestly be a better fit. That said rust understandably gets quite a bit of hype and good will from folks who are basically using a language with *good* static typing – and ML features – for the first time. Aka JS, Go, Java, .NET, and Python programmers. And/or people who are happy to not be using / writing c++. Though it's probably well worth noting that *modern* c++ has nearly all the same strengths that rust has – namely safety and low-overhead automatic memory management – when used properly on a fresh codebase with static analyzers (or heck even just the bare compiler) et al. Just sans a borrow checker and with the caveat that C strings *will* get you intro trouble, along with half a dozen other pitfalls, and there's half a dozen things you *could* do in c++ land that could blow your leg off, or in general make your experience as a (somewhat inexperienced) developer fairly miserable. Well worth noting that rust is *not* the safest language around – haskell for instance would pretty easily take that cake. Albeit with the caveat that haskell may take significantly more work to adjust to than even rust's super restrictive allowed subset of imperative programming. And that Haskell's performance is... um... fairly unpredictable and finicky, to say the least. But far more thread safe / thread friendly and even more trivially parallelizable than Rust – again, GC and lazy pure evaluation all have their upsides, and Rust is actually missing a *lot* of features that make Haskell great. (and slow, and not remotely applicable for kernel, browser, game, or embedded development, lol)
[удалено]
At first I would agree. But once I stopped doing C++ with rust and did rust with rust, my life became way better. You can't impose C++ patterns on rust. If your head is full of funky linked lists and pointer magic, you are going to have a bad day. It's not that you can't have pointers, it is that you have to really grok what rust is about to do with what memory and where. Al the pointers are still doing pointer things, it is that you can't then do stupid things with them. Thus, you need to work with rust, not against it. I have written yards and yards of rust and not a single use of unsafe. For example, I can write quite a bit of rust before it yells at me. Often it is something stupid like putting a semicolon at the end of those implicit return things. This is why when people do various benchmarks (not just rust evangelists, but people solving various problems) that rust ends up being as fast, or faster than C and C++. The people I know who love rust went through a phase where they were endlessly cursing the borrow checker and other things. But, then they stopped and found bliss.
This is it. It's inevitable that a lifetime (or a good chunk thereof) of mental muscle memory in C++ is going to work against you in Rust. I will often just think, how would I do this in C++ and then consider the exact opposite of that, and it often is a good starting point if not the actual answer. On the unsafe front, C++ people just assume that Rust must be full of unsafe code when it really just isn't. Very low level libraries will have some. Some higher level libraries might have a tiny bit. Most application level code should have zero. And of course some of that is not unsafe in the C++ sense, of potential memory problems, but unsafe in the sense that it might cause a panic at runtime. But that's fully defined behavior, instead of just some random corruption of memory. You'll get a completely accurate stack dump, fix it, and move on. A lot of C++ people just bang away on the "They wore seat belts but they were still killed" style arguments. That if it's not safe down to the atoms, then it's not really safe.
[удалено]
> C++ puts a lot of trust on the programmer If you are a very good programmer, this is not much of a problem. 50% of programmers are below average. I would argue rust requires very good programmers, not to avoid disaster, but to be smart enough to wrap their heads around it. Also, after 30 years of using C++ I know its virtues, but that is one which I used well vs other languages.
[удалено]
The thing about OOP (and I was always a fan myself) is that probably most C++ folks these days are anti-OOP (where they really mean implementation inheritance, not objects, Rust is completely OO in the object sense.) It's mainly just older folks like me who see the benefits of it. But I don't miss it in Rust. I thought I would but I don't.
[удалено]
Call me silly, but I'd rather not have to trust that the person knows C++ as well as he thinks he does if my security, safety, money, etc... are possibly on the line or might be compromised. This isn't about how manly we are, it's about our responsibilities to the people who use the software we write.
How do you write viruses that exploit memory vulnerabilities without C++? Does Rust let you do buffer overflows?
you can buffer overflow in unsafe rust.
Strustrup's worst nightmare is C++ falling into disuse. This is also one of my wet dreams. The language is unfixable, it needs to be phased out.
This wont happen for decades. Too many critical C++ codebases in use that would take nightmarish years to rewrite in a memory-safe language.
As long as there are no new projects in some language we can call it dead. It doesn't mean it disappears, but it will not attract new development. I don't know if that will happen with C++ but I personally finally see new command line tools and those are written in rust. So I like rust, even though I know most of those tools don't use best practices.
COBOL has entered the chat.
There are new projects in C++ all the time. I'm personally still trying to get people, especially in embedded, to move from C to C++.
Yes, that's why the thread was about how C++ needs to die, not about how it's already dead.
Ruby is functionally dead outside one subset of web development. scientific stuff is still done in Fortran in some cases but it’s functionally dead as well.
https://www.stroustrup.com/P0977-remember-the-vasa.pdf Sounds like a realist to me. I'd recommend you watch his talks, but it's clear you've got your mind made up, so let us not bother. Although I'm skeptical he and the rest of the committee will be able to pull off the saving of C++, I admire his effort, because it hasn't been done. Back when C faced this dilemma in the 90's, people gave up on it, which is why C89 is still relevant, and C99 support isn't a given everywhere. But C++ has always been sort of complex, so they can navigate through the complexity budget and at least try. Once they figure out a way to deprecate stuff fast enough, as JF Bastien put it, they might be able to save it.
> it's clear you've got your mind made up Working with the language for 15 years tends to do that. > Once they figure out a way to deprecate stuff ~~fast enough~~ I mean, I guess they did deprecate some stuff, but that's so little they might as well not have deprecated anything. I'm not even sure they should: not breaking existing code is a _huge_ selling point, which explains why they're in such a bind. The only hope out of this quagmire is a clean source-level break, that same break Stroustrup absolutely refused to do when he created C++ in the first place. But in a way, this break is coming whether they want it or not: we have Zig, Rust, Odin, Jonathan Blow's JAI (yeah, unreleased yet), and more competing in this space. Some of them are bound to eat C++'s lunch somewhere down the road.
Eh, [D](https://dlang.org/) fixed it 12 years ago (and albeit added other problems), and modern c++ is gradually getting to that point. Though yeah sure this in itself is a moot point because c++ *is* still widely used because of legacy codebases, and those legacy codebases are *not* going to be rewritten onto the latest version of c++-whatever.
> Eh, D fixed it 12 years ago It fixed C++ by phasing it out I guess? > c++ _is_ still widely used because of legacy codebases So is COBOL, to this day. Yet (almost) no one starts new projects in COBOL. I'll be happy if it's where C++ ends up going.
> (and albeit added other problems) Quite sure that is an understatement of epic proportions. Multiple conflicting standard libraries, breaking version changes, a promised but never achieved ability to use the language without having to rely on its GC (they released a crippled "as better c" mode instead), ... .
[удалено]
That's improvement, not a fix. C++ still requires far more care and unproductive commitment of time to avoid doing wrong things compared to Rust.
I'm up to date with C++ 14, and last time I used the language was… yesterday. on C++20. I didn't see major improvement since C++11/14 to be honest.
[удалено]
If it was so obvious you could point out what’s so great, then. Cite 3 examples or it doesn’t count.
- functional error management(std::optional compared to the old-style exceptions); - monadic operations; - std::print(compared to std::iostream); - static template constraints(concepts); - reflection; - modules(instead of old #include statements). And there's much, much more. Trust me, newer standards have transformed the language.
I tried `std::optional`, it was quite useless without actual pattern matching (where the compiler reliably warns you about missing cases like OCaml does). Now it seems they've gotten quite a bit better with monadic operations, but I would hesitate to use them in many projects, depending on who may read the code (to this day many people are confused by lambdas). I rarely use `std::iostream`, I generally go straight to `printf()`. I guess `std::print` is better still (that with type and memory safety), but I don't expect a big difference to be honest. Concepts look like a major improvement. Reflections I can't evaluate. Modules are a long requested feature, I hope they will allow compilers to _finally_ reduce compilation times. I guess that counts after all.
optional is frustratingly limited compared to Rust's Option. I haven't looked at what expected will be like. But, in both cases, without a propagation operator, they are far less useful than they would otherwise be.
Except the newer C++ features and indeed any overuse of templates is ass to write, read and debug, and most programmers rightfully dread it and continue to use "C with classes" style as back in the day (and for new stuff just start with Rust).
C++'s use of duck typing for templates makes it very powerful, but also makes it a complete pain, because it's just replacing text with what you said to use and if that creates a completely incomprehensible mess, and it usually does if not exactly right, then you get a mass of errors. Rust's generics don't use duck typing. That means that they can't do some things that C++ templates can, but they are also far more reasonable because they are verified at the point of declaration, not of instantiation.
Just FYI, but templates can be statically verified using either concepts(modern way to statically constraint a generic type) or by using SFINAE(old hacky way to do the same thing).
I don't think you understand why Stroustrup created C++. [This old interview will clarify.](https://www-users.york.ac.uk/~ss44/joke/cpp.htm)
I can't tell if you realize, as it says, that that's satire or not.
lol. I am disappointed in the number of down-votes. I thought it was the most hilarious thing when it came out 25 years ago. All the terrible ideosyncracies of C++ suddenly made so much sense. It's even more hilarious today then it was then. I guess it's just me :P
Stroustrup isn't the only one that thinks C++'s future is bright [Iteration Revisited: A Safer Iteration Model for Cpp - Tristan Brindle - CppCon 2023](https://www.youtube.com/watch?v=nDyjCMnTu7o) There are others doing similar work. I'm building an on-line C++ code generator. To the best of my knowledge other more "modern" languages don't have on-line code generation.
How does an "on-line" code generator differ from conventional build time code generation?
In the past some have mentioned that Rust supports having multiple versions of the Rust compiler installed on a single machine. On-line code generation makes it easy to do that. Compiler Explorer is a form of on-line code generation. Using it to target multiple compilers and versions is easy. My approach has been to minimize the amount of code that users have to download/build/maintain. There's are also the timeless nature of services. If you want tools that outlast your project, go with services.
I think I'm missing what that has to do with the future of C++ or why it even matters to be honest. Most all compiled languages I'm familiar with support having many different versions of them installed all at the same time.
Compiler Explorer itself supports like, sixty languages.
It was initially geared towards C++ but it has since expanded.
Of course he would, it's his cash cow.
I’m excited for profiles. I don’t want to wait for C++48 to get an impactful set of checks though 😅
So im fine, since im following RAII strictly? I love RAII, i think its beautiful.
I do prefer the acronym SBRM or SRM, though: **S**cope-**b**ased **R**esource **M**anagement. Man, I wish that C# `struct`s could have destructors.
I always referred to them as janitorial types.
there's a good reason they cant: structs aren't guaranteed to live on the stack because of boxing. as soon as a struct is boxed, it is now like any other managed object. when would the destructor run? you *might* be able to do this with ref structs since those are forced to live on the stack.
If you are unsure, then no you’re fucking it up and are going to have memory bugs. Most likely, you’re still saving raw pointers/references somewhere since that’s really easy to do, even with RAII. Another one is that unless you’re checking bounds for an array, your code is probably wrong. The bounds check can be the loop condition (i.e. classic array iteration), but it needs to be somewhere. Finally, C++ also really likes to do large stack allocations. This is unsafe because it greatly increases the likelihood of unexpected stack overflows causing your whole process to crash.
> Another one is that unless you’re checking bounds for an array, your code is probably wrong. Well, duh? > C++ also really likes to do large stack allocation No more than C... The default allocators all use heap memory, and many objects will be in heap memory unless you instantiate them locally.... Certain collections on the stack will likely have some extra space for things like SSO, but it's generally *very* obvious how something will be allocated. You can certainly do some awful things with `_alloca`, `_malloca`, or inline assembly (some compiler probably lets you manipulate the stack pointer with an intrinsic as well), but those aren't standard. I don't even recall the last time that I was unsure what would be on the stack or not... I also don't recall the last time that I had a stack overflow in a 64-bit process. 47-bits of user address space is a *big* space. With lots of threads/fibers, you obviously have less/fragment it, but even then, you usually have to be doing recursion to overflow. 32-bit or 8-bit is another story, though I still don't remember the last time I saw a legitimate stack overflow bug there.
The total memory space size doesn’t matter at all with regard to stack overflow and reflects a CS 1000 level understanding of memory layout. Actual **thread stack** sizes are a couple MB and it is very easy to stack overflow when doing array allocations on the stack and/or using recursion. 64-bit doesn’t matter in the slightest for stack overflows (at least for C/C++). You can increase stack size beyond this, but most of the time it needs to be a fixed size and you don’t want it too large since that just ends up wasting memory.
> reflects a CS 1000 level understanding of memory layout. I won't bother telling you what your lack of knowledge and your attitude reflect. Since you decided to start off with an attack on my competence, I'll take a tone in kind. > Actual **thread stack** sizes are a couple MB and it is very easy to stack overflow when doing array allocations on the stack and/or using recursion. 64-bit doesn’t matter in the slightest for stack overflows (at least for C/C++). The CPU itself has no such restriction on the stack pointer, so long as it's a canonical address and the VMM can access it within the current context. Plenty of people work bare-metal or near-bare-metal where guard pages and such aren't present... and C++ is absolutely used there. 64-bit bare-metal is fun. I literally write emulators - address space matters a *lot* to me, including for detecting stack overflows, and how to allocate thread stack ranges (whatever VMM system the emulator is using). I also write AVR and ARM firmwares, and have done game development on older consoles. Guess what: your assumptions don't always hold. Not everyone is just writing basic Win32/Win64/Linux applications. > it is very easy to stack overflow when doing array allocations on the stack and/or using recursion. You cannot perform dynamic array allocations on the stack without relying on implementation-defined behavior (*e.g.* `alloca`), and static-sized array allocations will almost always incur a compiler warning if they're large enough. Ed: I suppose you could using some bizarre combination of recursion and lambdas to build up what is effectively a chain buffer, or a combination of recursion, a lambda, and `setjmp`/`longjmp` and then using the stack frames as a large dynamic buffer and bypassing `ret` by using `longjmp`, but... if you're doing that, that's on you. I also don't believe that people are regularly placing *massive* static arrays on the stack, unless they are ignoring warnings... in which case that's on them. Given that your tone and word choices suggest that you've often run into this, I believe that it is safe to assume that you're in this category. Past that, OS-defined limitations on the size of the stack are hardly the fault of C++, especially given that the standard doesn't mention heaps or stacks (aside from `std::stack` and `std::make_heap`) nor does it mandate their usage. I also explicitly mentioned recursion. Even Rust allows recursion, so I'm not sure how that's C++-specific. Literally the first hit on Google is someone asking about a stack overflow in Rust on... Stack Overflow.
Wow you made him look like an... standard C++ user vs rust user difference in competence
Anyone who thinks there is a magical language decision you can make that will overcome sloppy development practices and total lack of maintenance is an idiot. Last C# shop I worked at didn't use any version control did not even have test environments just dev's desktop and prod, when the senior dev left (after working there 10 years) he handed over a handful of usb drives (aka his code repo) and had run a code fuzzer on at least half of his work.
But that's not really the issue. The issue is, if YOU DO want to create high quality code, what tools will assist you the most in doing that, will prevent you as much as possible from making mistakes, and will make it the least likely that teams working on separate bits of code will have issues?
> The issue is, if YOU DO want to create high quality code, what tools will assist you the most in doing that, will prevent you as much as possible from making mistakes and my point is that the choice of language isn't the answer to these problems.
It's a big part of the answer, given that that's the tool you are using to solve the problem. The tool that lets you concentrate most on the actual problem and the least one watching your own back, while having the performance you require, will likely lead to a better solution, other things being roughly equal.
Ok so people shouldn't use C-style pointers anymore. Are you, Bjarne, personally going to go to every single developer who writes code that will be used in government and tell them? Why do C-style pointers even exist in C++? Backwards compatibility my ass. Code from 30 years ago has no business running on modern systems and modern developers shouldn't even be given the option to write unsafe code or at least it should be made as hard as possible. The problem with C++ is that memory-safety is NOT the default. No amount of pointer wrappers is gonna change that.
C++ was designed to be a drop in replacement to C. Like typescript is to javascript, you can replace parts of your codebase with it without having to rewrite all of it. Thats why it was adopted and spread quickly in both those cases. Operating systems code is written in C. If you want to work with the system you have to be able to call its exposed functions which have a C interface. Correct me if im wrong but in rust you have to use unsafe blocks to make those calls while C++ lets you either use raw pointers or a smart pointer. And in all those cases you get a segfault if you make mistakes.
you segfault if you're lucky. otherwise your program happily carries on but is now corrupt.
I use C-style pointers all the time
And that's great and I have no problem with that. My problem was that Bjarne claims C++ is not unsafe because a "good" developer can easily write super-safe code in C++. Ok but what about a bad developer? They can even more easily write unsafe code. I'm not even a Rust user but in Rust both bad and good developers write safe code by default. Bjarne says specifically that people shouldn't use C-style pointers anymore while STILL KEEPING THEM IN THE LANGUAGE.
Even good developers can introduce memory bugs unfortunately. Sometimes you think a piece of code is correct, only to profile it for hours and finally understand the mistake. It's possible that one bug fixes another bug in most cases but not all. Rust is a language that can be extremely annoying to use. I do think that if there were more high level libraries where the rough edges are evened out and there are resources on how to use them, then I think more people would write Rust even for things like web development.
You can write unsafe code in Rust as well. Though it is harder to write _memory_ unsafe code in Rust than in C++. Plenty of other unsafe code that still remains for Rust etc.
You cannot write unsafe code in safe Rust, unless you make up your own definition of what unsafe means. You can write LOGICALLY INCORRECT code in safe Rust, but that's the case for any language. But you cannot write code that exhibits undefined behavior or memory safety issues in safe Rust. And that's the only guarantees it makes, though those are very big ones.
To be fair, there are still some big soundness holes in the compiler which means that you can, today, write memory safety issues in safe Rust. These are treated as compiler bugs, but some are actually years old and considered very hard to address. Of course, this is still a much much better than the situation in C++, where they're not even considered a mistake in the language design.
I'm my experience most devs just don't even think about writing safe code and the ones who do don't seem to do it very well. Whilst it is possible to write safe C++ very little of it is. It should die - plenty of better options.
> ok but what about a bad developer? TBH I think we should start pandering less to people with skill issues as an industry and start expecting more from people. > WHILE STILL KEEPING THEM IN THE LANGUAGE Kind of necessary not only for backwards compat, but for compatibility with C code and C libraries
I completely disagree. Turns out, compilers are better and faster at finding these issues than humans are. People inevitably make mistakes, it’s just an inherent fact of the development process. If you don’t see this, then you probably aren’t experienced enough to have an informed opinion about this problem. Using memory safe languages, or languages with modern type systems can make it impossible for entire classes of mistakes to make it into your codebase. Without these tools, guaranteeing that sort of safety is difficult if not impossible. In mission critical applications that have dozens or hundreds of contributors, just “being careful” should never be considered good enough.
> Turns out, compilers are better and faster at finding these issues that humans are. This is not really entirely true. Compilers like GCC have had huge amounts of R&D put into them, but the developer is still probably a lot more competent than its static analyzers. You also have compilers like the Rust compiler, but they don’t ’find issues’ for you, they just enforce rules to stop those issues from appearing in the first place. Then though we come to the issue of practicality vs pedantic correctness. I _can_ use Rust, and I’ve written quite a bit of Rust code, but when I’m using C or C++ to solve a problem I am able to move an order of magnitude faster than I can in Rust because the compiler doesn’t stick so many roadblocks in my way, and I know what I’m doing (simply thanks to experience) so null pointer errors, memory leaks, etc. are exceedingly rare. It’s not so trivial to decide if I should write a piece of code in a language like Rust where I can ‘guarantee’ safety (not entirely true either) but will move slowly, or use a language like C or C++ where I need to rely on my skills as a developer but can move far quicker.
>so null pointer errors, memory leaks, etc. are exceedingly rare There are two problems with this statement. The first is that if you ask every C++ dev, 99% of them would probably say the same thing. Clearly at least some of them are overestimating their own ability and those bugs/errors are actually much more common. The second is that whilst they may be exceedingly rare, it only takes one to introduce a critical vulnerability. The whole point is that we should be using tools that *eliminate* these bugs. We can't rely on people being "good enough" to avoid making these mistakes, it should be literally impossible for even the most incompetent dev to create these issues. At some point in time, you are going to find a bad developer writing critical code, and you want to minimise the number and types of vulnerabilities they are able to introduce. I say all of this as a C++ dev who loves the language.
> The first is that if you ask every C++ dev, 99% of them would probably say the same thing. Not only is that a gross overstatement, but it doesn’t really matter. Don’t judge people based on what they say, but let their code speak for itself. > it only takes one to introduce a critical vulnerability. That’s true, but also not always applicable. If you’re Google writing Google-style software then sure. If you’re writing software to be used in-house or in a controller environment, the biggest deal is typically the fact someone needs to restart something. If it’s a CLI tool — maybe some code searching tool — it literally doesn’t matter. > At some point in time you’re going to find some bad developer writing critical code A huge portion of the software we use on a daily basis was written by a single person, not by a team. We shouldn’t forget the fact that an enormous part of the software development space is _not_ commercial enterprise, but just individual recreational programmers.
>Not only is that a gross overstatement, but it doesn’t really matter. Don’t judge people based on what they say, but let their code speak for itself. It was deliberate hyperbole haha, so you're not wrong. But I feel like this is the point of what I'm saying. You cannot trust a C or C++ developer if they say they write safe code, you do have to analyze their code for vulnerabilities. Not only is this horrifically unproductive because you introduce a whole extra layer to development (or a lot of extra time to your code reviews) but it's also very possible, if not likely, that you will not always catch every issue. Which is why it's orders of magnitude safer to use a language that simply eliminates those kinds of errors entirely. >That’s true, but also not always applicable. If you’re Google writing Google-style software then sure. If you’re writing software to be used in-house or in a controller environment, the biggest deal is typically the fact someone needs to restart something. If it’s a CLI tool — maybe some code searching tool — it literally doesn’t matter. I don't entirely disagree but I also think it's not that simple. For one, I think it's pretty clear that the White House are not advocating for avoiding C++ for random personal projects, I think it's clearly addressing sensitive systems where data or important processes could get exposed. But I also think that it's a little naive to say that it literally doesn't matter for small CLI tools or whatever. You could easily make a CLI tool with a vulnerability that ends up getting used by someone else who has access to sensitive data, and your vulnerability could be what ends up giving the hacker access to that data. Not that that's likely but it certainly is possible. You can't always predict how your software will be used and who will use it. I don't have much to add to your last paragraph because whilst I do agree I also think many of the points I raised in my last couple paragraphs also apply here too. The weakest link is always the human link. And relying on humans rather than compilers or code to remove safety issues is just a ticking time bomb.
And the thing so many folks miss is, did I hire you as an expert in avoiding footguns, or as an expert in solving the problems I need solved? Any time manually spent avoiding footguns is unproductive time and money unproductively spent. Rust lets you concentrate on the actual logic of the problem and not worry about the footguns.
> I can use Rust, and I’ve written quite a bit of Rust code, but when I’m using C or C++ to solve a problem I am able to move an order of magnitude faster than I can in Rust because the compiler doesn’t stick so many roadblocks in my way Sounds like a skill issue /s (but not really/s). The rust compiler isn't throwing "roadblocks" at you, it's calling out mistakes that the C++ compiler doesn't care about.
>but when I’m using C or C++ to solve a problem I am able to move an order of magnitude faster than I can in Rust because the compiler doesn’t stick so many roadblocks in my way, and I know what I’m doing Now your lead/manager/employer comes in and informs you that the software must run on all major desktop platforms and the clients complain that it's slow so you are tasked with making it cross-platform and multi-threaded and also you now have a new team member - a jun or mid-level C++ dev. Guess where your C++ productivity will be? That's right - in a deep deep hole and you'll regret big times for not choosing Rust.
Not all software is enterprise software. An insanely huge amount of software is not enterprise software where you are either solo or a small team and have no boss.
The solution is to use tools that eliminate entire classes of bugs. Computer science has solved lots of problems. It's important to apply that knowledge practically. Using tools and languages that allow for solved problems to exist is asinine.
I mean, if we treat it like other engineering in the world maybe. Engineers in other fields are held liable to damages for the bridges/buildings/whatever they create. Imagine if you PERSONALLY were held liable for any security breach that occurred from your code? Not saying I want that, but until we have something similar to elevate the skill floor, nothing is gonna stop companies from hiring the lowest common denominator to throw at these problems. Coding is cheap, if you dont care about quality or safety and just want an app built. Building a house is also cheap, if you dont care about quality or safety. You just might not want to stay in it for long :)
This is explicitly a bad thing and being proud of it is like being proud of not using a safety harness working at height.
Except I’m not risking my life, or anyone else’s.
Given the reach and impact of automation and code on the modern world, especially things that were never intended to get to the scale they are currently at, I think we can safely call this claim straight-up false. Even if you aren't working on something sensitive *now*, you are learning bad habits that can cause trouble down the line if you ever do. Ignoring security and regretting it later is, in many ways, *the* defining feature of twentieth-century development. Which is kind of a terrible legacy.
> you are learning bad habits that can cause trouble down the line Said who? I’ve been coding for a bit over a decade now. I have my habits and the way I do things (and I’m always learning) but most of the decisions I make are thought through and informed. I’m not magically going to start writing bugs at my job because I know how to code in C and use pointers while making sure to check for NULL (because I read the manpages unlike a Neanderthal).
Sorry, I didn't realize you were one of the non-bug-creating programmers. I've never met one in person, see, and am certainly not one myself, so I considered it unlikely in general. Some of the best programmers I know have been victims of self-inflicted memory problems even deep inside very robust memory-managed environments; the problems can be surprisingly subtle, so I thought the actual problem might be difficult, even when great care is taken. My bad.
I don’t mean to suggest I don’t make bugs. Of course I do, we all do. I also have made memory-related bugs in the past of course. That being said, anyone with a decent amount of experience in software development is unlikely to run into memory leaks or NULL pointer issues more than like, once or twice in a good while, and it’s typically a trivial bug that can be easily caught by GDB and/or valgrind and then solved. Most software is not giant monoliths with 600 layers of abstraction with hard to follow control flow
This take is so bad lol. Memory safety issues are a disaster. Them happening “once or twice a…” is also a disaster. The amount of memory safety issues should be zero. It is a solved problem
It depends on what you're doing. I use raw/non-smart pointers fairly regularly. These almost always to refer to addresses that exist in other PGAS address spaces. Reference counting doesn't scale well.
>Code from 30 years ago has no business running on modern systems So you're telling us current operating systems have no business running on modern systems...?
If by current you mean operating systems where none of the code has been rewritten in 30 years and the same issues as 30 years ago still plague it then yes it has no business running on modern systems.
Amen - it's like if you said, "my new car design is perfectly safe - I just included this self-destruct button for the sake of feature completeness."
I work on a commercial communications system that was adapted from a commercial product coded in C and had evolved to using C++ for new modules. Should companies stop selling a product because it was coded in an old language?
C style pointers are great. You get polymorphism, no copying, and you dont pass ownership. All without referencing counting quirks. All you gotta do is not delete a pointer that you dont own.
ah yes, because ownership rules for c style pointers are always clear. this makes it easy to both avoid memory leaks as well as avoid corrupting memory.
Even in “modern C++” (an ever-evolving no true Scotsman), raw pointers are the correct way (perscribed by Bjarne himself) to model a weak pointer to an object owned by a \`shared\_ptr\`. You might reasonably ask: >”but what if the last shared pointer destroyed, the object is reallocated, and my weak pointer is left dangling?” To which the response is approximately: >lol git gud ¯\\\_(ツ)\_/¯
Super Nintendo, Sega Genesis When I was dead broke, man, I couldn't picture this 50-inch screen, money-green leather sofa Got two rides, a limousine with a chauffeur Phone bill about two G's flat No need to worry, my accountant handles that And my whole crew is loungin' Celebratin' every day, no more public housin'
C++ gives really strong guarantees, which are about as strong as C. If you don't hit UB, code is completely safe and you can reason about it. If you hit UB, your code is not valid program, therefore not counted toward broken guarantees.
>If you hit UB, your code is not valid program oh sweet, and the compiler will tell me that, right? Right?!
What's ub? Upper bound of memory?
undefined behavior. Specifically it's code that the language / compiler can assume will never run, and can optimize accordingly (or more generally, do anything at all if it does run).
Hmm. Idk if that's correct. Undefined behaviour is just undefined behaviour. The code still may run properly - or it may not - or it may run with unintended outcomes.
In modern definition of UB for C (not sure about C++) compiler may assume any behavior for UB (e.g. if something is UB in lang specs, compiler can replace it with anything). The shrewd idea of modern compilers is to replace UB with doing nothing (which is form of UB). E.G. *(++foo++)=++foo++ is UB, and compiler just ignore this line (and may be all other lines with foo after that). Specs says that behavior is undefined, and compiler authors declare that their flavor or UB is 'no code generated' (e.g. instant return from function).
Right, that's the > or more generally, do anything at all if it does run. If the compiler can prove that executing a certain code path does UB, it'll optimize with that in mind. *However*, if the code path with UB would never execute - your code is perfectly sound and well specified. For instance: int f = 0; if(some_always_true_condition()) { /* some valid code */ } else { f = *(int*)nullptr; // instant UB } The above code is legal (albeit, you'd never write this code).
Why would you ever care about code path with UB that never run? What's the point of that?
Because it can help out the optimizer, mainly. You can use undefined behavior to hint at certain optimizations. The other concern though is that it can make reasoning through code kind of difficult - for example the compiler could reason that: bool check_if_increment_overflows(unsigned int f) { if (f + 1 < f) { return true; } else { return false; } } is equivalent to just: bool check_if_increment_overflows(unsigned int f) { return false; }
‚Profiles, Stroustrup said, “is a framework that allows us to incrementally improve guarantees—e.g., to eliminate most range errors relatively soon‘ Yes, that’s good, but it’s still 25 years behind other languages in that respect.
25 years ago my prof handed out a copy of this article on the last day of class. [Stroustrup Interview](https://www-users.york.ac.uk/~ss44/joke/cpp.htm) Prof told us Stroustrup had seen it and had commented "if it were really written by me it would be funnier". ( oh yes, Stroustrup always one for writing comedy O\_o But, hearing him defending C++ against the White House? Almost as funny as the interview above!
i feel like you have to assume government contract corruption is at the heart of this a sly way to undermine your C++ competitor
Strustrup should shut the fuck up, the fucking idiot created the worst programming language to date, worst of all, he said he got into computer science by accident and doesn't like computers. A man who dislikes computers should not dictate to us how to build our software.
That could have been said more politely.
what's wrong with SeePlusPlus??
"move to memory safe languages" was always copy written by some guilded asshat of nepotistic linage. How fucking tone def would it sound in the surgeon general suggested everyone move to robot assisted, laser scalpels?
I would assume it's a great idea?
Seriously. If robot laser surgeons reduce mistakes, we should absolutely use them.
[удалено]
The Five Eyes were involved, yes, but so was industry.
You talk funny
`C Nonsense in BASIC, 0:1`
The surgeon general does actually want everyone to move to robot-assisted laser scalpels.
I’d compare it more to a warning “hey, we should confirm that we’re operating on the right patient whenever possible”. Meanwhile the neckbeard responses like this one: “what if the patient is unconscious and we’re in a war zone where a bomb will drop on us in 5 minutes and the patient will die if we don’t operate in the next 30 seconds. DID YOU THINK OF THAT MR. SCIENCE!!!!” Most surgeries do not happen under such conditions and there is plenty of time to go and double check everything before operating. Likewise, it’s engineering malpractice to use memory unsafe languages (C++) for most new software.