11 ms·

C++ creator rebuts White House warning

74 points by joaogui1 3y ago

pornel 3y ago
This link is a mobile (AMP) version of the article that has been submitted already: https://news.ycombinator.com/item?id=39748953 https://news.ycombinator.com/item?id=39748953
arcticbull 3y ago
> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. The fundamental problem is they’re just guidelines and they’ll always be just guidelines. You can still do all the wild old stuff without so much as a warning and you’ll have to figure out how it even interacts with the new stuff which exposes yet another vector for failure.
- froh 3y ago
  linters nudge about not following guidelines, and project policies turn the Judges into enforcement.
  - arcticbull 3y ago
    Which is fine until you have third party dependencies.
Scubabear68 3y ago
Stroustrup as always fails to recognize the vast surface area of C++ features, foot cannons, and the heavy weight of C compatibility around C++ neck. C++ barely made sense in 1995. It makes absolutely no sense today.
- jeffbee 3y ago
  I think the funny thing is you no longer even get peak performance from C++. In many ways Java is running rings around C++ performance. Partly, it's because you get state-of-the-art peak optimizations for free from Java, and you'll need a team of 20 full-time build engineers to get a peak C++ artifact with PGO, LTO, and post-link optimizations. Partly it's because the speed of C++ is illusory, with the superficial success coming at the start of a project, followed by years of monotonic performance degradation as the flaws in the original are iteratively discovered and remediated. We see this very clearly with gRPC, where the performance of the C++ implementation has been cut in half over the last 3 years while the Java implementation, which is faster today than ever before, is the performance champion.
  - eclectic29 3y ago
    I acknowledge C++'s safety concerns, but no, Java is definitely NOT running rings around C++ perf. Not a single AI/ML model is implemented in Java. The core of AI/ML runs on C++ only. You may see a lot of Python, but the core engine that Python is wrapping is written in C++. Sorry to break it to you but Java cannot even come close here.
    - jeffbee 3y ago
      "Multiply an insane amount of stuff" is not an interesting point in complexity-safety-performance space.
      - miffy900 3y ago
        > "Multiply an insane amount of stuff" is not an interesting point in complexity-safety-performance space. So in other words, Java is bad at scaling a basic math operation like multiplication? > "In many ways Java is running rings around C++ performance" The AI-space is proof positive of that being false. C++ is kicking Java's butt, squeezing literally trillions of ops per second of performance, all of this happening before the Java runtime can even startup. The first transformer-based language model was built with PyTorth; imagine if PyTorch was a python wrapper for Java code instead of C++ code? It'd be garbage. I mean how freaking long did it take for Java to even get a basic Vector API? C++ devs have been writing SIMD optimized code for years now. And besides that, try getting a Java program to scale at tens or even hundreds or thousands of GPUs for a large language model. You'd need GPUs with literally 20-30% more RAM just to accommodate the GC.
klodolph 3y ago
> Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++. My CppCon 2023 keynote outlines that evolution, C++ safety may have improved a lot, but it’s still far, far behind most other languages we use. It’s not even a close comparison. You throw a bunch of programmers at a problem and you will get some number of bugs in the code. In C++, some percentage of those bugs will be memory errors. You can eliminate raw pointers but that doesn’t solve the problem—there are all sorts of places that dangling pointers crop up anyways, like in references that get captured in lambdas which get stored somewhere and then the programmer doesn’t realize that the lambda is called after the object is destroyed. I’ve seen various solutions proposed to these problems. The worst solution is to “just hire better programmers and be careful”. The easiest solution for greenfield projects, most of the time, is to pick a different language.
- amluto 3y ago
  I admit I mostly don’t understand the “modern C++ is safe” argument. I maintain a decent size C++ code base, I try to use modern features in good taste, and I do think that C++ has added a lot of nice things. But nice != safe. basic_string_view is new in C++17. It sure beats pointers, but it’s a far cry from the kind of safety that you get in essentially any other language (except C): it is a reference with unknown lifetime, and the toolchain does not help track that lifetime. I think that Stroustrup would say that the C++ Core Guidelines fix this, and I think he’s referring to this: https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf https://github.com/isocpp/CppCoreGuidelines/blob/master/docs... which seems like it’s maybe partly implemented in some version of Visual Studio and was maybe prototyped in clang. But it does not seem to be a well-specified language or a fully-implemented language, and I can’t use it now. So, as far as I’m concerned, I can use Rust or Python or Perl or Go or Swift or bash or Java or JavaScript or Haskell or Lisp or Scheme or O’Caml or Tcl and I can manipulate strings without worrying about undefined behavior. Or I can use C++ and worry. Or I can dream about using “Modern C++?”
  - kazinator 3y ago
    C++ is safe if you ignore most of its libraries and write everything from scratch, making safety your #1 priority, ahead of performance and everything else, and then doggedly stick to using nothing but the safe primitives you have created.
deleted 3y ago
[deleted]
kstrauser 3y ago
There's the language as idealized, and the language as used. Stroustrup is clearly brilliant, but he's talking about the former while everyone else means the latter. If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. That's, what, 0.1% of C++ projects? The rest of them use a soup of features and misfeatures that've been released in the spirit of trying to make everyone happy simultaneously. I am solidly in the camp that believes C++ is unsafe. With enough discipline and tooling, it is possible to write safe C++. Are there more than a sliver of shops jumping through those hoops? Of course, there may be a survivorship bias involved that proves me wrong. If it turned out that every remaining C++ shop is great at writing C++ code, because all the shops that weren't gave up and migrated to something else, I wouldn't be shocked.
- cqqxo4zV46cp 3y ago
  > If it turned out that every remaining C++ shop is great at writing C++ code, because all the shops that weren't gave up and migrated to something else, I wouldn't be shocked. I would. Almost all conversations about C/C++ security are, to this day, alive with people that are in my opinion delusional. The survivorship bias is more that the community is left with an over-representation of people that take “it’s often impractical for a team to write secure C/C++” as a personal attack against their intelligence and choose to dig their heels in as a result.
  - moomin 3y ago
    Boy do I have some codebases I could show you. I mean, the biggest problem isn’t that they’re written in C++, but it really didn’t help either.
- lazypenguin 3y ago
  > With enough discipline and tooling, it is possible to write safe C++ I think it's possible to write "safe enough" C++ for real-world use. Then after some time you get a weird crash because MSVC stdlib implementation does something weird in new spec. Or your dependency does something unsafe and hoses you. Or the new guy uses `std::string_view` but forgot it doesn't guarantee null-termination. Or you casually forget about iterator invalidation because you're tired and compiler doesn't help you. Or or or. I like C++, it's a nice language but after befriending Rust compiler, or seeing how awesome hot reload in C# is or live-coding a front-end in javascript or any other advantages of other languages I find the use-case for C++ shrinking daily. Really if the C++ ecosystem wasn't so damn rich with libraries, tools and more I doubt it would have as much backing today.
throw7 3y ago
Yeah. The language you pick doesn't magically make you Fort Knox regardless of "memory safety". Rewind in time and the White House would be berating all of us to write in Java... you know... a "memory safe" language, only for the worst security fail to come along Log4Shell.
- kstrauser 3y ago
  I don't like Java. Nothing about it appeals to me. It pains my eyes to look at it. And in spite of my distaste for it, I respect that it completely eliminates giant classes of vulnerabilities. You can write bad logic in any language. At least in Java you can't write bad logic that also suffers from memory issues.
  - owlstuffing 3y ago
    > At least in Java you can't write bad logic that also suffers from memory issues. Oh you bet you can. There are a number of ways to screw that up. - memory leaks/loitering is quite common, gc won’t help if your code hangs on to stale refs - using Unsafe memory can blow up in glorious C++ fashion, directly or indirectly - using native calls incorrectly can be just as nasty
    - ttfkam 3y ago
      I'd wager Unsafe in Java is far more rare per million lines of code written than unsafe blocks in Rust. Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare). (Cue the one weird guy coming out of the woodwork who claims that all of his Java projects in the last 10 years have used Unsafe to great effect.)
      - owlstuffing 3y ago
        > Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Your project may not use it directly, but there’s a pretty good chance one of your libraries does.
marcus0x62 3y ago
> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that If only people were perfect, then things would be perfect. There’s, what, 40 years of evidence to suggest that most people, most of the time, simply cannot write memory-safe C++ code (50 years if you count C.) Maybe we should continue the experiment for another 50 years, just to be really sure the language is the problem.
- 7e 3y ago
  Programmer education, tools, language standards and best practices are all vastly different than 50 years ago. That's like pointing at a Ford Edsel and then claiming that modern humans can't make good cars.
  - marcus0x62 3y ago
    I’m not pointing at a contemporary akin to Ford or Edsel. I’m pointing at people today using the latest versions of these tools today making the same class of mistake as someone might have made 4 or 5 decades ago. The tool is the problem.
    - moomin 3y ago
      Ironically, Margaret Hamilton _was_ able to produce a bug free program back in the 60s. However, no-one is seriously considering replicating her techniques because they (some of them, ant least) are way too expensive for modern software.
      - marcus0x62 3y ago
        1) The Apollo Guidance Computer software was not bug-free[0] 2) The AGC software was not written in C++ The NASA approach to software development undoubtedly results in high quality assurance, but at a huge productivity cost that most commercials shops could not shoulder. What do you do about the huge amount of software that needs to be developed that is too complex and cannot justify things like having 5 independent concurrent executions running two completely separate but functionally identical code bases tested by a completely independent adversarial test team? I’d argue you could start by using tools that don’t allow, let alone encourage, your programmers to make common mistakes with catastrophic consequences. 0 — see, for instance, https://ibiblio.org/apollo/Documents/COM-1.pdf https://ibiblio.org/apollo/Documents/COM-1.pdf
jvanderbot 3y ago
The amount of iconoclastic knee jerking in this thread is kinda nuts. Equating this rebuttal to an old man yelling at clouds? Saying Cpp never made sense? The first step to solving a problem is accepting reality. Cpp has been foundational, like C, to our computing world. If the rich legacy of libraries that underpin our "better" language choices is offensive to us, or if we really believe we are powerless to improve the situation around the most popular programming language(s) then we're not being realistic. This is a huge debate of national importance and it'll shape programming language design for decades, it's important to get this right, and that will take more than just once choice and more than one approach to get right.
- klodolph 3y ago
  > The first step to solving a problem is accepting reality. Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. And yes—you also can’t throw C++ in the garbage. Both of those statement are part of our reality—C++ is unsafe, and we will use it anyway. That’s why we solve this problem on two fronts. First, we advise programmers to ditch C++ for safer languages, when reasonable, because C++ isn’t safe enough for most needs. Second, we invest a lot of energy into making C++ safer, with better tools, safer libraries, changes to compilers, static analysis, run-time instrumentation, etc. It won’t close the gap—C++ is still unsafe and will be for the foreseeable future—but it will make a big difference to the people who, for whatever reasons, still use C++ despite its safety problems. The C++ FAQ has a better picture here: https://isocpp.org/wiki/faq/big-picture https://isocpp.org/wiki/faq/big-picture > In 99% of the cases, programming language selection is dominated by business considerations, not by technical considerations. Things that really end up mattering are things like availability of a programming environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, and corporate culture/politics. These business considerations generally play a much greater role than compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic binding, etc. There are a lot of good reasons to use C++. C++ is also unsafe. Both are true. We don’t need to write long apologia explaining why C++ is actually safe, and you shouldn’t be looking at legacy code, or you need to hire better programmers, or you’re using the wrong tools or wrong practices or something like that. Ultimately, those arguments don’t withstand scrutiny.
kable7 3y ago
[flagged]
moomin 3y ago
I mean, you can call it a rebuttal, but this: “There are two problems related to safety. Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that,” sounds like an admission that, following decades of improvements and modernisations to C++, safety and quality remain a practical concern in most actual C++ codebases. In many ways it’s surprising that it has taken this long to call time on it. I can understand Stroustrup’s frustration; the work they’ve been doing has been excellent, but there’s nothing stopping industry or the government switching to other options that are making better headway against problems like this.
CyberEldrich 3y ago
Bjarne Stroustrup: Remember the Vasa! (2018) https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0... Bjarne Stroustrup 2018: We are on a path to disaster though enthusiasm and design-by-committee (or rather “design-by-committees”). During the early days of WG21 the story of the Vasa was popular as warning against overelaboration (from 1992): “Please also understand that there are dozens of reasonable extensions and changes being proposed. If every extension that is reasonably well-defined, clean and general, and would make life easier for a couple of hundred or couple of thousand C++ programmers were accepted, the language would more than double in size. We do not think this would be an advantage to the C++ community.” “We often remind ourselves of the good ship Vasa. It was to be the pride of the Swedish navy and was built to be the biggest and most beautiful battleship ever. Unfortunately, to accommodate enough statues and guns it underwent major redesigns and extension during construction. The result was that it only made it half way across Stockholm harbor before a gust of wind blew it over and it sank killing about 50 people.” “It has been raised and you can now see it in a museum in Stockholm. It is a beauty to behold - far more beautiful at the time than its unextended first design and far more beautiful today than if it had suffered the usual fate of a 17th century battle ship -- but that is no consolation to its designer, builders, and intended users.”
cedws 3y ago
He seems to be in denial. I watched Stroustrup's CppCon 2023 talk about safety[0] a few months back. He spends about an hour talking about how important safety is and all the new things C++ offers to write safe code. Why did he suddenly start caring about safety now? C++ is like a mad hatter's bad acid trip and somehow people are convinced it's still a great language to use in 2024. [0]: https://www.youtube.com/watch?v=I8UvQKvOSSw https://www.youtube.com/watch?v=I8UvQKvOSSw
- janice1999 3y ago
  Is that the talk where Stroustrup avoids even saying the word Rust for the entire talk even though the talk is 100% a reaction to Rust? On the other hand Herb Sutter recently wrote an interesting and grounded article on his views of Safety. While I don't agree 100% with him, at least he acknowledges the position C++ is in. Edit: The article: https://herbsutter.com/2024/03/11/safety-in-context/ https://herbsutter.com/2024/03/11/safety-in-context/
- beached_whale 3y ago
  He isn’t talking about memory safety and keeps avoiding it.
- nox101 3y ago
  The obvious answer would seem to be he's afraid of the (slow) death of C++ which is his legacy/child. No one wants to see their work thrown on the scrap pile of history.
- throwaway2202 3y ago
  I’m going off old memory here, but I happened to have his C++ book in late 90s. I read that before I learn C. In intro he claimed strongly no need to learn C. Just learn C++. I was young and just followed his wisdom. Obviously there’s zero replacement for learning C before C++. I can at best say I lost a lot of time confused about basic stuff. Until I gave up, ignored him and learnt C like I should have. I was in school, I did not expect to come across faith based software development. That’s a different course.
1970-01-01 3y ago
Can C++ be safe? Absolutely! Does a jr. developer know how to avoid all the pitfalls and craft this magical, safe code? No examples can be shown.
Cloudef 3y ago
Even such basics as initialization is full of traps in C++, its truly language thats awful to produce anything safe with. C on the other hand isnt a bad language, but C's problem comes from the horrible standard library and bad standard. You can create much better C by passing -fno-strict-aliasing -ftrapv -fsigned-char to the compiler even now. Heck rust's unsafe is more unsafe than C. "C" could be improved with a better compiler that ignores the standard, but perhaps it wouldnt be C anymore even if the syntax remained the same. C++ problem is not helped by the compilers either, shoutouts to msvc++ accepting absolutely wrong and horrible code by default.
- amluto 3y ago
  IMO the problem with C isn’t just the horrible standard library. It’s that you can’t make a better standard library — the language constructs needed to abstract almost anything don’t really exist.
  - Cloudef 3y ago
    The standard library consists many functions that simply should be dropped. All the globals like errno, locale should be removed. Instead of global allocator, allocator struct should be passed around (zig). Headers like stddef and stddint in the standard library should be in the language instead. https://github.com/Cloudef/zig-budoux/blob/master/src/c.zig#L9 https://github.com/Cloudef/zig-budoux/blob/master/src/c.zig#...
    - amluto 3y ago
      All true, but that still doesn’t mean that there will ever be a genuinely nice string type or map from string to int or a nice HTTP or any similar thing where some of the data types are dynamically sized.
      - Cloudef 3y ago
        struct and few functions and you get there. Look at zig's std lib. "String" type is also IMO anti-pattern https://mortoray.com/the-string-type-is-broken/ https://mortoray.com/the-string-type-is-broken/ People often complain about null terminated "strings" in C, but I don't really see them as a problem. It rarely is performance bottleneck, and when it is you can opt for your own "string type". There is also bstring that's compatible with these strings but prepend header to the data which contains the length. That said I wish C had language level slicing.
pizlonator 3y ago
C++ is an unsafe language in all of its current implementations except CHERI. Stroustrup is being tone deaf or maybe he just doesn’t get it. The issue is that there are so many ways in which you could write a C++ expression that violates memory safety and gives users control of your heap. In Java or other truly safe languages, there are zero ways to do that short of pwning the JVM with a bug. In Rust and other safe systems languages, to do something unsafe you have to call it out using the unsafe keyword. So - the places in your C++ code where you might have a memory safety violation are everywhere while in the alternatives they are either nowhere or they are carefully demarcated.
pizlonator 3y ago
I wish that rather than making excuses, C++ apologists switched to trying to just make the whole language memory safe. It’s possible. There just aren’t good incentives in place to do it.
- sseagull 3y ago
  I've long held that belief. But doing so is very technical and political, and not fun. Turns out what is more fun is to create a new language and rewrite the whole ecosystem. So a lot of the energy is going there instead. Programming is part fashion...
  - pizlonator 3y ago
    Yeah. Building a new language from scratch is definitely easier than retrofitting new properties into the semantics of an existing one. Hasn’t stopped me from trying though. :-) And the CHERI folks are trying, too. So it’s really more of a political problem than a technical one. The excuse extravaganza that we’re seeing from Stroustrup and Sutter doesn’t help at all.
eclectic29 3y ago
With all due respect Stroustrup seems completely delusional about real software out there in the wild. He needs a dose of reality.
drewolbrich 3y ago
TL;DR: Bjarne Stroustrup is frustrated that the authors of the government's proposal don't realize that, theoretically, there may exist teams of talented developers who are able to consistently write safe C++ code.
- deleted 3y ago
  [deleted]
twelfthnight 3y ago
Really sad to see such an influential computer scientist lose interest in advancing computing for the perceived slight against his legacy. Ironically I think Stroupstrup is actually doing more harm than good to his reputation by "evolving" C++ than simply putting it in maintenance mode and contributing to a modern language.
- Scubabear68 3y ago
  I agree. I think he could have done wonders starting fresh with something new.
vlovich123 3y ago
So what it sounds like: Strousoup: The future is a yet to be defined profiles. Sutter: The future is a yet to be defined C++v2 that's backwards compatible but also solves the problems. Chandler: C++ compile times are too slow. Going to build a brand new front-end that really fixes compile performance and maybe fixes memory safety & let's you call C++ code. My take: Re Strousoup: From what I've seen, Strousoup's ideas don't seem particularly extra likely to make it to the final standard and that's when he already has a formal standard written up. Prognosis: Modules were much simpler (conceptually at least), took ~6 years, and even 4 years after coming out have seen minimal adoption. This definitely isn't on track for C++26 and likely will encounter real-world roadblocks by C++30. If everything goes well, the industry would be ready to start adopting profiles in ~10 years. Or they could start using Rust today. Still quite vague in terms of whether or not this idea can be implemented by compiler authors. Re C++v2: Vague hand-waving without a real plan on how to be meaningfully competitive with Rust. Since it's an experiment and experiments can fail, unlikely to lead anywhere and unlikely to see industry adoption. Re Carbon: interesting experiment and the most likely real-world candidate to displace C++. Being done by a company with a massive C++ codebase that would benefit from migration to Carbon. From the looks of it, they're spending most of their time on compile performance. Neat technical experiment but not really showing that a language that's bidirectionally compatible with C++ can meaningfully improve on safety. Also, Rust compile times have improved significantly in the past few years and are better than C++ in my experience (but of course, hard to have a fair comparison of the two and I'm compiling these days on a much faster machine than I've used for C++ in the past). The recent Cranelift work might reasonably speed things up another ~2-3x. EDIT: TLDR: C++ today is not safe enough and no idea when it will be, regardless of the work going on to try to make it safer with no idea when that might happen.
- froh 3y ago
  hooray! a down to earth stay with the facts response! thank you for that. if I'm not mistaken, Chandler and Sutter lead efforts to untangle what we have, sucht that we can then improve upon it, with better templates/metaprogramming or borrow annotations or bounds checking containers etc. for C++ especially it's really two things that make it hard: it's idiosyncracies (that's what they work on) and then in addition the lack of these new abilities.
haolez 3y ago
What makes me wary of jumping to Rust is the async stuff. From what I read, colored functions were introduced and most of the libraries that do useful stuff adopted async and kind of force you to be aware of it in your own code. For me, the perfect C++ replacement would be something like Go without the runtime burden. I'm not sure that this exists, so I use Go whenever I can and C++ in the ultra rare cases where I can't.
- pornel 3y ago
  This "color" thing is a terrible miscommunication, because the original article is about two things that don't even make sense in Rust's context: • an architectural limitation of JavaScript which Rust doesn't have (in Rust you can wait for an async result in a sync function, or run CPU-heavy code from an async function). • a wish that languages had implicit magic that made sync and async calls look the same, which Rust intentionally doesn't want, because implicit magic is a terrible footgun in low-level code. It can be hidden in a high-level VM language that is in charge of all I/O, syscalls, and locks. But that is counter-productive for a low-level systems language for implementing I/O drivers, kernel syscalls, and custom locking primitives. So Rust is "purple". In reality Rust's async is awesome for what it is: a syntax sugar for state machines, which is able to flatten an entire call tree into a single fixed-size struct. Most other async architectures need at least one allocation per async call or per await, but Rust needs one allocation per the entire call graph with any number of async calls and awaits.
- techbrovanguard 3y ago
  If you want to call an async function from a sync context, use `futures::executor::block_on`. Nobody is forcing you to use async.
AlotOfReading 3y ago
Stroustrup needs to realize that "just wait a few more years" isn't an acceptable answer when you're already a decade late to the party. The white house is not some radical pioneer at the frontier of programming language design. By the time it says anything on the subject, it's been obvious to everyone else for years. There might be a reasonable discussion here if we were discussing profiles when the earliest incarnations of it appeared around 2015, but we're not. It's 2024 and they're still not in the standard. There isn't even a clear proposal for compilers to begin implementing. Once there is, profiles will still be an optional, partial, and incremental solution at best. They won't even fulfill Stroustrup's stated desires to address all kinds of safety (for which there hasn't even been discussion yet).
- shrimp_emoji 3y ago
  Bjarne is simply pointing out that if we wait for static analysis tools to become sentient thanks to upcoming breakthroughs in AI and quantum computing, we can finally have fewer CVEs in C++ software. > The white house is not some radical pioneer at the frontier of programming language design. By the time it says anything on the subject, it's been obvious to everyone else for years. That we should return to Ada? ;p Oh, wait, sorry; I have no idea what that is. We need Rust.
snitty 3y ago
>https://www.reddit.com/r/cpp/comments/14vcvxg/c_makes_it_easy_to_shoot_yourself_in_the_foot_c/ https://www.reddit.com/r/cpp/comments/14vcvxg/c_makes_it_eas... This you bro?
deleted 3y ago
[deleted]
singularity2001 3y ago
tangentially nothing in my career made me as angry as working through Bjarnes Book because none of the examples worked (that was an early edition of the book maybe later editions added the necessary includes etc)
keithalewis 3y ago
Table saw manufacturers wonder why Exacto knife users are so worried about their fingers getting cut off. The simple and obvious explanation is we now live in a world where many people are too lazy and/or dumb to spend time learning the tools of their trade. 3..2..1
EPWN3D 3y ago
I just want a safe-ish language that doesn't nerd-snipe 95% of software engineers into creating glorious and incomprehensible syntactic monstrosities that go nuts with allocations and hidden function calls. Really hoping Zig getting some more traction.
kazinator 3y ago
> Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++ This rhetoric from Stroustrup comes off as disingenuous; what saves it from being outright dishonest is the wording "an aim". As in one of many. Not "the aim". Firstly, of course we get a jump in safety from K&RC to C++. But most of the development of C++ has been driven by a hedge between multiple factors, only one of those being safety, and not always having the top priority. Factors like: ease of implementation, performance, safety and backward compatibility. We can point to recently introduced library features that are not safe, and easily identify backward compatibility issues that prevent improvements in safety. In the 1990's, C++ introduced a standard library of containers. If safety had been the top priority, iterators would never have had undefined behavior when the target object changes, and std::vector would have been impervious to out-of-bounds accesses. These things could easily have been achieved in what is just library code. A C++ developer can easily ignore the library, and develop their own containers with safe iterators, vectors that can't be misused and other elements. The standard didn't do that because of those other factors: ease of implementation and performance. (Can someone point to three situations in the development of C++ in which safety ran up against efficiency or implementation ease, and did not lose?)

74 points by joaogui1 3y ago

This link is a mobile (AMP) version of the article that has been submitted already: https://news.ycombinator.com/item?id=39748953 https://news.ycombinator.com/item?id=39748953

arcticbull 3y ago

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. The fundamental problem is they’re just guidelines and they’ll always be just guidelines. You can still do all the wild old stuff without so much as a warning and you’ll have to figure out how it even interacts with the new stuff which exposes yet another vector for failure.

froh 3y ago
linters nudge about not following guidelines, and project policies turn the Judges into enforcement.
- arcticbull 3y ago
  Which is fine until you have third party dependencies.

Scubabear68 3y ago

Stroustrup as always fails to recognize the vast surface area of C++ features, foot cannons, and the heavy weight of C compatibility around C++ neck. C++ barely made sense in 1995. It makes absolutely no sense today.

jeffbee 3y ago
I think the funny thing is you no longer even get peak performance from C++. In many ways Java is running rings around C++ performance. Partly, it's because you get state-of-the-art peak optimizations for free from Java, and you'll need a team of 20 full-time build engineers to get a peak C++ artifact with PGO, LTO, and post-link optimizations. Partly it's because the speed of C++ is illusory, with the superficial success coming at the start of a project, followed by years of monotonic performance degradation as the flaws in the original are iteratively discovered and remediated. We see this very clearly with gRPC, where the performance of the C++ implementation has been cut in half over the last 3 years while the Java implementation, which is faster today than ever before, is the performance champion.
- eclectic29 3y ago
  I acknowledge C++'s safety concerns, but no, Java is definitely NOT running rings around C++ perf. Not a single AI/ML model is implemented in Java. The core of AI/ML runs on C++ only. You may see a lot of Python, but the core engine that Python is wrapping is written in C++. Sorry to break it to you but Java cannot even come close here.
  - jeffbee 3y ago
    "Multiply an insane amount of stuff" is not an interesting point in complexity-safety-performance space.
    - miffy900 3y ago
      > "Multiply an insane amount of stuff" is not an interesting point in complexity-safety-performance space. So in other words, Java is bad at scaling a basic math operation like multiplication? > "In many ways Java is running rings around C++ performance" The AI-space is proof positive of that being false. C++ is kicking Java's butt, squeezing literally trillions of ops per second of performance, all of this happening before the Java runtime can even startup. The first transformer-based language model was built with PyTorth; imagine if PyTorch was a python wrapper for Java code instead of C++ code? It'd be garbage. I mean how freaking long did it take for Java to even get a basic Vector API? C++ devs have been writing SIMD optimized code for years now. And besides that, try getting a Java program to scale at tens or even hundreds or thousands of GPUs for a large language model. You'd need GPUs with literally 20-30% more RAM just to accommodate the GC.

klodolph 3y ago

> Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++. My CppCon 2023 keynote outlines that evolution, C++ safety may have improved a lot, but it’s still far, far behind most other languages we use. It’s not even a close comparison. You throw a bunch of programmers at a problem and you will get some number of bugs in the code. In C++, some percentage of those bugs will be memory errors. You can eliminate raw pointers but that doesn’t solve the problem—there are all sorts of places that dangling pointers crop up anyways, like in references that get captured in lambdas which get stored somewhere and then the programmer doesn’t realize that the lambda is called after the object is destroyed. I’ve seen various solutions proposed to these problems. The worst solution is to “just hire better programmers and be careful”. The easiest solution for greenfield projects, most of the time, is to pick a different language.

amluto 3y ago
I admit I mostly don’t understand the “modern C++ is safe” argument. I maintain a decent size C++ code base, I try to use modern features in good taste, and I do think that C++ has added a lot of nice things. But nice != safe. basic_string_view is new in C++17. It sure beats pointers, but it’s a far cry from the kind of safety that you get in essentially any other language (except C): it is a reference with unknown lifetime, and the toolchain does not help track that lifetime. I think that Stroustrup would say that the C++ Core Guidelines fix this, and I think he’s referring to this: https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf https://github.com/isocpp/CppCoreGuidelines/blob/master/docs... which seems like it’s maybe partly implemented in some version of Visual Studio and was maybe prototyped in clang. But it does not seem to be a well-specified language or a fully-implemented language, and I can’t use it now. So, as far as I’m concerned, I can use Rust or Python or Perl or Go or Swift or bash or Java or JavaScript or Haskell or Lisp or Scheme or O’Caml or Tcl and I can manipulate strings without worrying about undefined behavior. Or I can use C++ and worry. Or I can dream about using “Modern C++?”
- kazinator 3y ago
  C++ is safe if you ignore most of its libraries and write everything from scratch, making safety your #1 priority, ahead of performance and everything else, and then doggedly stick to using nothing but the safe primitives you have created.

deleted 3y ago

[deleted]

kstrauser 3y ago

There's the language as idealized, and the language as used. Stroustrup is clearly brilliant, but he's talking about the former while everyone else means the latter. If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. That's, what, 0.1% of C++ projects? The rest of them use a soup of features and misfeatures that've been released in the spirit of trying to make everyone happy simultaneously. I am solidly in the camp that believes C++ is unsafe. With enough discipline and tooling, it is possible to write safe C++. Are there more than a sliver of shops jumping through those hoops? Of course, there may be a survivorship bias involved that proves me wrong. If it turned out that every remaining C++ shop is great at writing C++ code, because all the shops that weren't gave up and migrated to something else, I wouldn't be shocked.

cqqxo4zV46cp 3y ago
> If it turned out that every remaining C++ shop is great at writing C++ code, because all the shops that weren't gave up and migrated to something else, I wouldn't be shocked. I would. Almost all conversations about C/C++ security are, to this day, alive with people that are in my opinion delusional. The survivorship bias is more that the community is left with an over-representation of people that take “it’s often impractical for a team to write secure C/C++” as a personal attack against their intelligence and choose to dig their heels in as a result.
- moomin 3y ago
  Boy do I have some codebases I could show you. I mean, the biggest problem isn’t that they’re written in C++, but it really didn’t help either.
lazypenguin 3y ago
> With enough discipline and tooling, it is possible to write safe C++ I think it's possible to write "safe enough" C++ for real-world use. Then after some time you get a weird crash because MSVC stdlib implementation does something weird in new spec. Or your dependency does something unsafe and hoses you. Or the new guy uses `std::string_view` but forgot it doesn't guarantee null-termination. Or you casually forget about iterator invalidation because you're tired and compiler doesn't help you. Or or or. I like C++, it's a nice language but after befriending Rust compiler, or seeing how awesome hot reload in C# is or live-coding a front-end in javascript or any other advantages of other languages I find the use-case for C++ shrinking daily. Really if the C++ ecosystem wasn't so damn rich with libraries, tools and more I doubt it would have as much backing today.

throw7 3y ago

Yeah. The language you pick doesn't magically make you Fort Knox regardless of "memory safety". Rewind in time and the White House would be berating all of us to write in Java... you know... a "memory safe" language, only for the worst security fail to come along Log4Shell.

kstrauser 3y ago
I don't like Java. Nothing about it appeals to me. It pains my eyes to look at it. And in spite of my distaste for it, I respect that it completely eliminates giant classes of vulnerabilities. You can write bad logic in any language. At least in Java you can't write bad logic that also suffers from memory issues.
- owlstuffing 3y ago
  > At least in Java you can't write bad logic that also suffers from memory issues. Oh you bet you can. There are a number of ways to screw that up. - memory leaks/loitering is quite common, gc won’t help if your code hangs on to stale refs - using Unsafe memory can blow up in glorious C++ fashion, directly or indirectly - using native calls incorrectly can be just as nasty
  - ttfkam 3y ago
    I'd wager Unsafe in Java is far more rare per million lines of code written than unsafe blocks in Rust. Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare). (Cue the one weird guy coming out of the woodwork who claims that all of his Java projects in the last 10 years have used Unsafe to great effect.)
    - owlstuffing 3y ago
      > Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Your project may not use it directly, but there’s a pretty good chance one of your libraries does.

marcus0x62 3y ago

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that If only people were perfect, then things would be perfect. There’s, what, 40 years of evidence to suggest that most people, most of the time, simply cannot write memory-safe C++ code (50 years if you count C.) Maybe we should continue the experiment for another 50 years, just to be really sure the language is the problem.

7e 3y ago
Programmer education, tools, language standards and best practices are all vastly different than 50 years ago. That's like pointing at a Ford Edsel and then claiming that modern humans can't make good cars.
- marcus0x62 3y ago
  I’m not pointing at a contemporary akin to Ford or Edsel. I’m pointing at people today using the latest versions of these tools today making the same class of mistake as someone might have made 4 or 5 decades ago. The tool is the problem.
  - moomin 3y ago
    Ironically, Margaret Hamilton _was_ able to produce a bug free program back in the 60s. However, no-one is seriously considering replicating her techniques because they (some of them, ant least) are way too expensive for modern software.
    - marcus0x62 3y ago
      1) The Apollo Guidance Computer software was not bug-free[0] 2) The AGC software was not written in C++ The NASA approach to software development undoubtedly results in high quality assurance, but at a huge productivity cost that most commercials shops could not shoulder. What do you do about the huge amount of software that needs to be developed that is too complex and cannot justify things like having 5 independent concurrent executions running two completely separate but functionally identical code bases tested by a completely independent adversarial test team? I’d argue you could start by using tools that don’t allow, let alone encourage, your programmers to make common mistakes with catastrophic consequences. 0 — see, for instance, https://ibiblio.org/apollo/Documents/COM-1.pdf https://ibiblio.org/apollo/Documents/COM-1.pdf

jvanderbot 3y ago

The amount of iconoclastic knee jerking in this thread is kinda nuts. Equating this rebuttal to an old man yelling at clouds? Saying Cpp never made sense? The first step to solving a problem is accepting reality. Cpp has been foundational, like C, to our computing world. If the rich legacy of libraries that underpin our "better" language choices is offensive to us, or if we really believe we are powerless to improve the situation around the most popular programming language(s) then we're not being realistic. This is a huge debate of national importance and it'll shape programming language design for decades, it's important to get this right, and that will take more than just once choice and more than one approach to get right.

klodolph 3y ago
> The first step to solving a problem is accepting reality. Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. And yes—you also can’t throw C++ in the garbage. Both of those statement are part of our reality—C++ is unsafe, and we will use it anyway. That’s why we solve this problem on two fronts. First, we advise programmers to ditch C++ for safer languages, when reasonable, because C++ isn’t safe enough for most needs. Second, we invest a lot of energy into making C++ safer, with better tools, safer libraries, changes to compilers, static analysis, run-time instrumentation, etc. It won’t close the gap—C++ is still unsafe and will be for the foreseeable future—but it will make a big difference to the people who, for whatever reasons, still use C++ despite its safety problems. The C++ FAQ has a better picture here: https://isocpp.org/wiki/faq/big-picture https://isocpp.org/wiki/faq/big-picture > In 99% of the cases, programming language selection is dominated by business considerations, not by technical considerations. Things that really end up mattering are things like availability of a programming environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, and corporate culture/politics. These business considerations generally play a much greater role than compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic binding, etc. There are a lot of good reasons to use C++. C++ is also unsafe. Both are true. We don’t need to write long apologia explaining why C++ is actually safe, and you shouldn’t be looking at legacy code, or you need to hire better programmers, or you’re using the wrong tools or wrong practices or something like that. Ultimately, those arguments don’t withstand scrutiny.

kable7 3y ago

[flagged]

moomin 3y ago

I mean, you can call it a rebuttal, but this: “There are two problems related to safety. Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that,” sounds like an admission that, following decades of improvements and modernisations to C++, safety and quality remain a practical concern in most actual C++ codebases. In many ways it’s surprising that it has taken this long to call time on it. I can understand Stroustrup’s frustration; the work they’ve been doing has been excellent, but there’s nothing stopping industry or the government switching to other options that are making better headway against problems like this.

CyberEldrich 3y ago

Bjarne Stroustrup: Remember the Vasa! (2018) https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0... Bjarne Stroustrup 2018: We are on a path to disaster though enthusiasm and design-by-committee (or rather “design-by-committees”). During the early days of WG21 the story of the Vasa was popular as warning against overelaboration (from 1992): “Please also understand that there are dozens of reasonable extensions and changes being proposed. If every extension that is reasonably well-defined, clean and general, and would make life easier for a couple of hundred or couple of thousand C++ programmers were accepted, the language would more than double in size. We do not think this would be an advantage to the C++ community.” “We often remind ourselves of the good ship Vasa. It was to be the pride of the Swedish navy and was built to be the biggest and most beautiful battleship ever. Unfortunately, to accommodate enough statues and guns it underwent major redesigns and extension during construction. The result was that it only made it half way across Stockholm harbor before a gust of wind blew it over and it sank killing about 50 people.” “It has been raised and you can now see it in a museum in Stockholm. It is a beauty to behold - far more beautiful at the time than its unextended first design and far more beautiful today than if it had suffered the usual fate of a 17th century battle ship -- but that is no consolation to its designer, builders, and intended users.”

cedws 3y ago

He seems to be in denial. I watched Stroustrup's CppCon 2023 talk about safety[0] a few months back. He spends about an hour talking about how important safety is and all the new things C++ offers to write safe code. Why did he suddenly start caring about safety now? C++ is like a mad hatter's bad acid trip and somehow people are convinced it's still a great language to use in 2024. [0]: https://www.youtube.com/watch?v=I8UvQKvOSSw https://www.youtube.com/watch?v=I8UvQKvOSSw

janice1999 3y ago
Is that the talk where Stroustrup avoids even saying the word Rust for the entire talk even though the talk is 100% a reaction to Rust? On the other hand Herb Sutter recently wrote an interesting and grounded article on his views of Safety. While I don't agree 100% with him, at least he acknowledges the position C++ is in. Edit: The article: https://herbsutter.com/2024/03/11/safety-in-context/ https://herbsutter.com/2024/03/11/safety-in-context/
beached_whale 3y ago
He isn’t talking about memory safety and keeps avoiding it.
nox101 3y ago
The obvious answer would seem to be he's afraid of the (slow) death of C++ which is his legacy/child. No one wants to see their work thrown on the scrap pile of history.
throwaway2202 3y ago
I’m going off old memory here, but I happened to have his C++ book in late 90s. I read that before I learn C. In intro he claimed strongly no need to learn C. Just learn C++. I was young and just followed his wisdom. Obviously there’s zero replacement for learning C before C++. I can at best say I lost a lot of time confused about basic stuff. Until I gave up, ignored him and learnt C like I should have. I was in school, I did not expect to come across faith based software development. That’s a different course.

1970-01-01 3y ago

Can C++ be safe? Absolutely! Does a jr. developer know how to avoid all the pitfalls and craft this magical, safe code? No examples can be shown.

Cloudef 3y ago

Even such basics as initialization is full of traps in C++, its truly language thats awful to produce anything safe with. C on the other hand isnt a bad language, but C's problem comes from the horrible standard library and bad standard. You can create much better C by passing -fno-strict-aliasing -ftrapv -fsigned-char to the compiler even now. Heck rust's unsafe is more unsafe than C. "C" could be improved with a better compiler that ignores the standard, but perhaps it wouldnt be C anymore even if the syntax remained the same. C++ problem is not helped by the compilers either, shoutouts to msvc++ accepting absolutely wrong and horrible code by default.

amluto 3y ago
IMO the problem with C isn’t just the horrible standard library. It’s that you can’t make a better standard library — the language constructs needed to abstract almost anything don’t really exist.
- Cloudef 3y ago
  The standard library consists many functions that simply should be dropped. All the globals like errno, locale should be removed. Instead of global allocator, allocator struct should be passed around (zig). Headers like stddef and stddint in the standard library should be in the language instead. https://github.com/Cloudef/zig-budoux/blob/master/src/c.zig#L9 https://github.com/Cloudef/zig-budoux/blob/master/src/c.zig#...
  - amluto 3y ago
    All true, but that still doesn’t mean that there will ever be a genuinely nice string type or map from string to int or a nice HTTP or any similar thing where some of the data types are dynamically sized.
    - Cloudef 3y ago
      struct and few functions and you get there. Look at zig's std lib. "String" type is also IMO anti-pattern https://mortoray.com/the-string-type-is-broken/ https://mortoray.com/the-string-type-is-broken/ People often complain about null terminated "strings" in C, but I don't really see them as a problem. It rarely is performance bottleneck, and when it is you can opt for your own "string type". There is also bstring that's compatible with these strings but prepend header to the data which contains the length. That said I wish C had language level slicing.

pizlonator 3y ago

C++ is an unsafe language in all of its current implementations except CHERI. Stroustrup is being tone deaf or maybe he just doesn’t get it. The issue is that there are so many ways in which you could write a C++ expression that violates memory safety and gives users control of your heap. In Java or other truly safe languages, there are zero ways to do that short of pwning the JVM with a bug. In Rust and other safe systems languages, to do something unsafe you have to call it out using the unsafe keyword. So - the places in your C++ code where you might have a memory safety violation are everywhere while in the alternatives they are either nowhere or they are carefully demarcated.

pizlonator 3y ago

I wish that rather than making excuses, C++ apologists switched to trying to just make the whole language memory safe. It’s possible. There just aren’t good incentives in place to do it.

sseagull 3y ago
I've long held that belief. But doing so is very technical and political, and not fun. Turns out what is more fun is to create a new language and rewrite the whole ecosystem. So a lot of the energy is going there instead. Programming is part fashion...
- pizlonator 3y ago
  Yeah. Building a new language from scratch is definitely easier than retrofitting new properties into the semantics of an existing one. Hasn’t stopped me from trying though. :-) And the CHERI folks are trying, too. So it’s really more of a political problem than a technical one. The excuse extravaganza that we’re seeing from Stroustrup and Sutter doesn’t help at all.

eclectic29 3y ago

With all due respect Stroustrup seems completely delusional about real software out there in the wild. He needs a dose of reality.

drewolbrich 3y ago

TL;DR: Bjarne Stroustrup is frustrated that the authors of the government's proposal don't realize that, theoretically, there may exist teams of talented developers who are able to consistently write safe C++ code.

deleted 3y ago
[deleted]

twelfthnight 3y ago

Really sad to see such an influential computer scientist lose interest in advancing computing for the perceived slight against his legacy. Ironically I think Stroupstrup is actually doing more harm than good to his reputation by "evolving" C++ than simply putting it in maintenance mode and contributing to a modern language.

Scubabear68 3y ago
I agree. I think he could have done wonders starting fresh with something new.

vlovich123 3y ago

So what it sounds like: Strousoup: The future is a yet to be defined profiles. Sutter: The future is a yet to be defined C++v2 that's backwards compatible but also solves the problems. Chandler: C++ compile times are too slow. Going to build a brand new front-end that really fixes compile performance and maybe fixes memory safety & let's you call C++ code. My take: Re Strousoup: From what I've seen, Strousoup's ideas don't seem particularly extra likely to make it to the final standard and that's when he already has a formal standard written up. Prognosis: Modules were much simpler (conceptually at least), took ~6 years, and even 4 years after coming out have seen minimal adoption. This definitely isn't on track for C++26 and likely will encounter real-world roadblocks by C++30. If everything goes well, the industry would be ready to start adopting profiles in ~10 years. Or they could start using Rust today. Still quite vague in terms of whether or not this idea can be implemented by compiler authors. Re C++v2: Vague hand-waving without a real plan on how to be meaningfully competitive with Rust. Since it's an experiment and experiments can fail, unlikely to lead anywhere and unlikely to see industry adoption. Re Carbon: interesting experiment and the most likely real-world candidate to displace C++. Being done by a company with a massive C++ codebase that would benefit from migration to Carbon. From the looks of it, they're spending most of their time on compile performance. Neat technical experiment but not really showing that a language that's bidirectionally compatible with C++ can meaningfully improve on safety. Also, Rust compile times have improved significantly in the past few years and are better than C++ in my experience (but of course, hard to have a fair comparison of the two and I'm compiling these days on a much faster machine than I've used for C++ in the past). The recent Cranelift work might reasonably speed things up another ~2-3x. EDIT: TLDR: C++ today is not safe enough and no idea when it will be, regardless of the work going on to try to make it safer with no idea when that might happen.

froh 3y ago
hooray! a down to earth stay with the facts response! thank you for that. if I'm not mistaken, Chandler and Sutter lead efforts to untangle what we have, sucht that we can then improve upon it, with better templates/metaprogramming or borrow annotations or bounds checking containers etc. for C++ especially it's really two things that make it hard: it's idiosyncracies (that's what they work on) and then in addition the lack of these new abilities.

haolez 3y ago

What makes me wary of jumping to Rust is the async stuff. From what I read, colored functions were introduced and most of the libraries that do useful stuff adopted async and kind of force you to be aware of it in your own code. For me, the perfect C++ replacement would be something like Go without the runtime burden. I'm not sure that this exists, so I use Go whenever I can and C++ in the ultra rare cases where I can't.

pornel 3y ago
This "color" thing is a terrible miscommunication, because the original article is about two things that don't even make sense in Rust's context: • an architectural limitation of JavaScript which Rust doesn't have (in Rust you can wait for an async result in a sync function, or run CPU-heavy code from an async function). • a wish that languages had implicit magic that made sync and async calls look the same, which Rust intentionally doesn't want, because implicit magic is a terrible footgun in low-level code. It can be hidden in a high-level VM language that is in charge of all I/O, syscalls, and locks. But that is counter-productive for a low-level systems language for implementing I/O drivers, kernel syscalls, and custom locking primitives. So Rust is "purple". In reality Rust's async is awesome for what it is: a syntax sugar for state machines, which is able to flatten an entire call tree into a single fixed-size struct. Most other async architectures need at least one allocation per async call or per await, but Rust needs one allocation per the entire call graph with any number of async calls and awaits.
techbrovanguard 3y ago
If you want to call an async function from a sync context, use `futures::executor::block_on`. Nobody is forcing you to use async.

AlotOfReading 3y ago

Stroustrup needs to realize that "just wait a few more years" isn't an acceptable answer when you're already a decade late to the party. The white house is not some radical pioneer at the frontier of programming language design. By the time it says anything on the subject, it's been obvious to everyone else for years. There might be a reasonable discussion here if we were discussing profiles when the earliest incarnations of it appeared around 2015, but we're not. It's 2024 and they're still not in the standard. There isn't even a clear proposal for compilers to begin implementing. Once there is, profiles will still be an optional, partial, and incremental solution at best. They won't even fulfill Stroustrup's stated desires to address all kinds of safety (for which there hasn't even been discussion yet).

shrimp_emoji 3y ago
Bjarne is simply pointing out that if we wait for static analysis tools to become sentient thanks to upcoming breakthroughs in AI and quantum computing, we can finally have fewer CVEs in C++ software. > The white house is not some radical pioneer at the frontier of programming language design. By the time it says anything on the subject, it's been obvious to everyone else for years. That we should return to Ada? ;p Oh, wait, sorry; I have no idea what that is. We need Rust.

snitty 3y ago

>https://www.reddit.com/r/cpp/comments/14vcvxg/c_makes_it_easy_to_shoot_yourself_in_the_foot_c/ https://www.reddit.com/r/cpp/comments/14vcvxg/c_makes_it_eas... This you bro?

deleted 3y ago

[deleted]

singularity2001 3y ago

tangentially nothing in my career made me as angry as working through Bjarnes Book because none of the examples worked (that was an early edition of the book maybe later editions added the necessary includes etc)

keithalewis 3y ago

Table saw manufacturers wonder why Exacto knife users are so worried about their fingers getting cut off. The simple and obvious explanation is we now live in a world where many people are too lazy and/or dumb to spend time learning the tools of their trade. 3..2..1

EPWN3D 3y ago

I just want a safe-ish language that doesn't nerd-snipe 95% of software engineers into creating glorious and incomprehensible syntactic monstrosities that go nuts with allocations and hidden function calls. Really hoping Zig getting some more traction.

kazinator 3y ago

> Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++ This rhetoric from Stroustrup comes off as disingenuous; what saves it from being outright dishonest is the wording "an aim". As in one of many. Not "the aim". Firstly, of course we get a jump in safety from K&RC to C++. But most of the development of C++ has been driven by a hedge between multiple factors, only one of those being safety, and not always having the top priority. Factors like: ease of implementation, performance, safety and backward compatibility. We can point to recently introduced library features that are not safe, and easily identify backward compatibility issues that prevent improvements in safety. In the 1990's, C++ introduced a standard library of containers. If safety had been the top priority, iterators would never have had undefined behavior when the target object changes, and std::vector would have been impervious to out-of-bounds accesses. These things could easily have been achieved in what is just library code. A C++ developer can easily ignore the library, and develop their own containers with safe iterators, vectors that can't be misused and other elements. The standard didn't do that because of those other factors: ease of implementation and performance. (Can someone point to three situations in the development of C++ in which safety ran up against efficiency or implementation ease, and did not lose?)