17 ms·

C++ Should Be C++

134 points by steveklabnik 3y ago

fancyfredbot 3y ago
What is the proposed legislation referred to in this article?
- nickm12 3y ago
  I have not heard anything about legislation, but the NSA and CISA have been arguing for the industry to embrace memory safe languages: https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... Even without legislation, I could imagine that the US government could try to enact software procurement rules that favor or require memory-safe implementations.
gavinray 3y ago
Honestly, the changes in C++ 20 and 23, plus the upcoming changes for 26 (looking at you, Concurrency TS v2) have so drastically improved the language it's almost like the ES5 -> ES6 evolution of JavaScript. I might be in the minority here, but I genuinely enjoy writing modern C++. My complaints are about it's dependency management story and lack of integrated, standardized tools for things like dependencies, testing, logging, etc.
- JohnFen 3y ago
  I don't know if you're in the minority or I am, but I find modern C++ to be borderline intolerable (and I've been programming mostly in C++ from before there were C++ compilers). I used to love C++ (and still do if we're talking about older standards), but the new stuff is just a baroque torture.
  - eps 3y ago
    Aye, same here. I don't mond C++ evolving into some thing of its own beyond all recognition, but there is a distinct lack of modern "C with Classes" language. Basically, C on steroids. There are attempts at that, but none is perfect and/or has enough traction to be viable.
    - WanderPanda 3y ago
      I just want a C with templates (and function overloading)?
      - eps 3y ago
        "this" and virtual functions are pretty damn useful too.
    - CuriousCosmic 3y ago
      You can still have "C with Classes" in modern C++ if you really want that. Just set a style guide that limits your code to that. There's more viable coding styles in C++ than I can honestly even bother to count. There's absolutely no reason to limit the language to one specific coding style when doing so would alienate large groups of users and you can set those limits yourself on your project.
      - JohnFen 3y ago
        This is what I do for my own projects, but it's not a viable thing to do with my work projects since I don't set the style.
      - eps 3y ago
        Yeah, I know and that's how I've been using it for the past decade, but it's not that simple. The language keeps changing and this forces adding cruft to the code if one wants to use newer compilers. For example, there are cases where the existence of move semantics necessitates adding some boilerplate when working with STL containers. There's no functional reason for it, just something to please the compiler.
    - 3y ago
- Night_Thastus 3y ago
  Anything C++11 forward is alright with me, though 17 introduces some very nice conveniences like <execution>, <filesystem> and most critically <optional>. Honorable mention to std::clamp too.
  - ska 3y ago
    > Honorable mention to std::clamp too. One shudders to think how many times variations of that template have been written in house.
    - Night_Thastus 3y ago
      Heck, I find so many cases where std::min and std::max could be used as well.
  - frfl 3y ago
    23 introduced <expected> (result/either) as well
  - spacechild1 3y ago
    I would like to add: - structured bindings - auto parameters in lambdas - init statements in if and switch clauses - template argument deduction for constructors
- TillE 3y ago
  You're absolutely not in the minority, old C++ was awful and there have been so many improvements to the language and standard library to help write simpler, clearer code. I was just recently appreciating the if statement with an initializer in C++17, which helps me express exactly what I want for variable scope in one line instead of multiple awkward ones.
oldpersonintx 3y ago
this feels defeatist c++ is with us for the near future, it needs an evolutionary path that provides a sane path forward why not break with the past? anyone needing to compile c++11 can find the tools and still use them, they can live in the past as long as they like just getting dependency/build management and integrated testing would be huge and really a small ask given what is happening in other tools its crazy that you still can't make sane use of things like modules, even if you fully commit to "modern" c++
- pphysch 3y ago
  Lack of modules support is the biggest thing keeping me from doing more c++ greenfield. So much friction in managing a pointless interface<->implementation layer.
  - frfl 3y ago
    I'm not well versed in C++ best practices, but unless it's a non-option for your situation, have you considered single file headers or perhaps even a unity build[1] approach? Of course, both are just workarounds for proper module support and have their drawbacks and limitations. [1]: https://en.wikipedia.org/wiki/Unity_build https://en.wikipedia.org/wiki/Unity_build
  - u_name 3y ago
    Yes! Proper modules support would give c++ a well needed boost (no pun intended!). msvc is kinda there, but it breaks here and there with intellisense.
- Night_Thastus 3y ago
  This is the never-ending problem with programming languages. If you make big breaking changes, the community suffers - even if the changes are very well intentioned. Look at the long tail of Python 2 vs 3 issues. If it happens once it's not so bad, but the older the community and the greater the size of its existing ecosystem - the more that pain becomes. Rust, from what I've seen, understands this issue.
EdSchouten 3y ago
> What is much less prevalent is a demand from average C++ users for memory safety features; they’re much more concerned about compilation speed. When most C++ developers haven’t adopted tools like Coverity and C++ core guidelines checkers, it is hard to claim that memory safety features substantially improve their lives at least from their point of view. I don’t really agree with this. There’s also a group of developers that want more safety, but don’t feel like setting up (or in the case of Coverity purchasing) additional tooling. Some people just want a decent out of the box experience.
- moffkalast 3y ago
  I think it's less about not wanting memory safety and more that compilation speeds are so time-wastingly abysmal that it's a few orders of magnitude more important to address. The whole deal with interpreted languages was to avoid sitting there for a few minutes every time you make a god damn one letter change, with the unfortunate but usually acceptable trade-off of some execution speed.
  - mxmlnkn 3y ago
    And the additional trade-off that some bugs are only noticed at runtime when that particular line is executed while it could have been noticed by the compiler of a strongly typed language. Pytype helps but at this point you have a static analyzer that potentially runs as slow as a compiler without the additional performance benefit.
    - moffkalast 3y ago
      Idk as long as you can develop at speed I don't see why a static analyser that's a few times slower than compiling couldn't run on the latest commit overnight? More as a sonarqube type thing I suppose.
    - josephg 3y ago
      There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.
diath 3y ago
Nevermind the language itself, we need a way to pull compilers and project dependencies, pinned to their specific versions, with a single, ergonomic tool. vcpkg seemed really promising but the fact that they didn't start with library versioning from the get go was a very stupid decision, and nowadays versions are pinned to specific commit hashes rather than actual dependency versions, and libraries that weren't previously versioned cannot be fetched if your project relies on an older pre-vcpkg version of a library and cannot be upgraded for one reason or another. These days I find myself struggling more and more with proper dev setup where I have an up-to-date compiler on any machine I want to build the code along with its libraries without running into a rabbit hole of compiler and library issues.
- bqmjjx0kac 3y ago
  Have you looked into Bazel? https://bazel.build/start/cpp https://bazel.build/start/cpp It's not always easy to use, but the focus on reproducible builds and caching is really nice. Edit: I guess it doesn't fetch a specific compiler for you by default, but you could probably ship your toolchain somewhere and pin it in your WORKSPACE file.
  - steveklabnik 3y ago
    Don't forget buck2 as well.
- andrewmcwatters 3y ago
  vcpkg was dead in the water because they altered source packages. Completely unacceptable in many situations.
  - kimixa 3y ago
    I also find vcpkg extremely fragile. Not in that pinning versions or the APIs or the actual contents of the packages we rely on, so much that every time we update a (rather small) set of dependencies there's nearly always some weirdness around vcpkg itself or the builds. Just the last week we updated to a newer tag and building openssl failed setting up the nasm build dependency, claiming it already existed. Which it did - there was a "nasm" folder in the tools directory it was trying to install it in, from the last time it was installed presumably and somehow got it's internal state messed up. But this caused a fatal error. I eventually worked around it by deleting the nasm directory from every build machine and letting it reinstall exactly the same package again. But the time before there was also a "random" build error, claiming that xz wasn't installed, despite the log showing it was just installed as a dependency in the line above. I guess this was fixed upstream, as the "workaround" was to use a tag from a month or so previous, but now seems to be fixed. Perhaps I'm using it wrong, perhaps you should "always" completely blast away the global vcpkg folder (and any vcpkg stuff cached in build directories from it's cmake integration) every time you touch it. But it's still time and effort for something that probably should be seamless.
lisper 3y ago
> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. No, that is false. It is akin to arguing that Christianity must be true because 2.4 billion Christians can't be wrong. The fallacy is easy to see because the argument can be applied equally to the world's 1.9 billion Muslims and 1.2 billion Hindus and 500 million Buddhists, etc. And yet these groups hold mutually-exclusive positions and so at least N-1 of them must be wrong. Humans are social animals. With only a few exceptions, we tend to conform to the group. That tends to make us get stuck in very deep ruts. "Everyone is doing it" is absolutely no indication that "it" is a good idea. [UPDATE] A lot of people seem to be missing the point here, so I feel the need to clarify: I'm not saying C++ is analogous to a relgion. I'm using the exclusivity of religious belief just as a short-cut to show that it is possible for large groups of people to hold false beliefs without getting into the weeds of which of those beliefs are actually false. The point is not that C++ is analogous to a religion, just that "adoption by millions" is not a valid argument for its merits. [UPDATE2] I am also not saying that religion has no value beyond the truth of its objective claims. I am only saying that (some of) the world's major religions do make objective claims, some of those claims are mutually exclusive, and so some of them must be objectively false, and therefore it is manifestly true that large groups of people can hold objectively false beliefs, and therefore the fact that large groups of people hold a position is not evidence that that position is objectively true. Being "fit as a general purpose programming language" is an objective claim.
- paulddraper 3y ago
  Awful analogy. C++'s fitness as a general-purpose programming language is not an exclusive assertion.
  - rcthompson 3y ago
    That's not the point. The point is that "N people can't be wrong" is not a valid argument for any value of N.
    - Rexxar 3y ago
galkk 3y ago
I like that this doc at least says that C++ is unergonomic. I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations. And when you look into C++ libraries/stdlib, they often look like they're written in another language entirely. This is not normal.
- professoretc 3y ago
  > I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations. Why would that be true? When you write a library, you are writing code to cover all possible uses; everything within the scope of your library should at least be considered, even if you personally have no need of that particular bit of functionality. But when you write a program it only has to do one thing, so of course it's going to be simpler. To me, it seems obvious that (good) library code will be very different from (good) application code. (I've used libraries that were written like applications, but they were bad libraries; I was constantly fighting the fact that the library author wrote only for their own use-case, and didn't consider any other.)
  - josephg 3y ago
    I hear you. But I’ve also learned a lot about how to write idiomatic rust from scrolling through rust’s standard library. You’re right - because it’s written to support lots of programs, it sure is packed with a lot of functions I’ll probably never use. But it’s still quite beautiful and readable. Much more so than C++. Here’s std::vec: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html https://doc.rust-lang.org/src/alloc/vec/mod.rs.html I tried to read C++’s vec class when I was learning C++ and I was confused and lost. I agree with the GP post - it feels like another language.
    - ativzzz 3y ago
      I'm not very familiar with rust, but isn't the point to mostly avoid `unsafe` and write safe code? Strange that basic std vec functions like insert and remove call `unsafe` - isn't this an example where you don't want to be like the std lib?
blt 3y ago
I feel the C++ committee saw the major quality-of-life improvements from C++11 and convinced themselves that Python's ergonomics with templated C++'s speed was possible. I won't say it's impossible, but the backwards compatibility sure seems like too much weight.
KerrAvon 3y ago
Is this a response to some specific set of proposals? I know there's been a lot of general angst / misunderstanding over C++ memory safety.
- tempodox 3y ago
  What's to misunderstand? There is no memory safety in C++.
- IshKebab 3y ago
  It's a response to Rust. Rust is significantly better than C++, and most importantly it's the first language that could actually replace C++ for the things C++ is generally used for. I guess the C++ community is coming to terms with not being the top dog of "zero-cost abstraction" languages anymore. Really I think it's too late for C++. They had literal decades to fix very basic flaws, and they just haven't done it. Accidental octal literals. Case fall-through. Missing `return`s. Accidental string literal addition. The whole module system mess. They focused way too much on adding complex features and not at all on fixing footguns. As a result C++ is painful and dangerous. Too late to fix IMO.
CoolGuySteve 3y ago
> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. Everywhere in the std lib you can see compromises that require rewriting substantial portions for any real time application. Things like: shared_ptr eagerly using atomics whenever possible; std::string allocating; the lack of built-in faster std::allocator replacements like bump allocators, memory pools, etc; no lockless and wait free concurrency primitives; no architecture-aware thread pools or even architecture descriptions; no IPC primitives; etc. Considering how many C++ developers are working on things like games, high performance server applications, databases, and operating systems, it's just bizarre how inappropriate the standard headers are for these tasks. Even something trivial like casting bytes off the wire to a packed struct is an exercise in frustration due to aliasing rules that should have been encoded in the type system and invisible to the user.
- zozbot234 3y ago
  Why does this have to be part of the standard library? Isn't that the whole point of Boost, that one is not limited to what's in std?
  - CoolGuySteve 3y ago
    It depends on the contributors, but boost also almost always fails to consider performance implications. For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time. The alignment of incentives between these library authors and people that use C++ for high performance applications is just off.
    - gumby 3y ago
      > For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time. It’s also the opposite: a place where possible candidates for the standard get tried out first. But like you, I rarely use it.
  - 3y ago
weinzierl 3y ago
"upcoming anti-C++ safety regulations" Is this a thing really or just FUD?
- omoikane 3y ago
  Probably related to things like these: https://news.ycombinator.com/item?id=33560227 https://news.ycombinator.com/item?id=33560227 - NSA urges orgs to use memory-safe programming languages
- steveklabnik 3y ago
  What is a real thing: various government organizations arguing that projects should move towards memory safe languages. What is not a real thing: regulations requiring such. Some think regulations may come, others don't.
- unstruktured 3y ago
  Not familiar with said regulations, but Ada was a good example of not using C++ for these very reasons in a military context.
- barryrandall 3y ago
  It's both and neither. Some countries are considering legislation to require "memory-safe" tooling for "critical" workloads, and C++ has never been placed on the "memory-safe tooling" list.
  - steveklabnik 3y ago
    Which countries? Can you share the reporting on this legislation? I’d be very interested.
    - dtolnay 3y ago
      The best forecast I know is Sean Parent's on ADSP episode 160. [0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical components will get rewritten into Rust or another memory-safe language. [0:24:28] CH: When you say "pending legislation", is that a nod to some pending legislation that you actually know is on the horizon? Or just anticipating that it's going to happen at some point? [0:24:38] SP: Oh yeah, no. There are two bills (sorry I don't have...) [0:24:44] CH: It's all right, we'll find them and link them in the show notes afterward. [0:24:48] SP: Yeah, I can hunt down the links. The one in the U.S. that's pending basically says that the Department of Defense is going to within 270 days of the bill passing (and it's a funding bill which means it will probably pass late this year - early next year) that the Department of Defense will establish guidelines around safety and security including memory safety for software products purchased by Department of Defense. The E.U. has a similar wording in a bill that's slowly winding its way through their channels. I don't have insight into when that will pass. The U.S. one will almost certainly pass here within a month or two. [0:25:43] CH: Oh. Wow. [0:25:44] SP: There's a long way between having a bill pass that says almost a year later they have to establish a plan for what they're going to do, right. So it's not hard legislation in any way. But I view this-- I can send you a link. There was a podcast I listened to recently on macOS folklore. [...] It's talking about how in the early '90s there was a somewhat similar round of legislation that went around around POSIX compliance. Basically the Department of Defense decided that in order to have portable software, every operating system that they purchased had to have POSIX compliance. And there was a roadmap put into place. That's why Apple pursued building their own UNIX which was A/UX and eventually partnered with IBM to do AIX. And Microsoft in the same timeframe had a big push to get POSIX compliance in Windows OS. The thinking was eventually in order to sell to the government your operating system it would require POSIX compliance. What actually happened, if you wanted to buy just traditional Macintosh operating system you would just say "well I require Photoshop or pick-your-application and there is no alternative that runs under UNIX so therefore I need an exception to buy macOS" and it was extra paperwork but it got signed off on. So really never materialized into hard restrictions on sales of non-POSIX-compliant OSes. I expect the safety legislation to take somewhat the same route, which is, there will be pressure to write more software in memory-safe languages. When you don't write software in memory-safe languages there is going to be more pressure for you to document what your process is to mitigate the risks. And this is initially all in the realm of government sales, although there is some discussion in both the E.U. legislation and on the U.S. side of extending this to a consumer safety issue. But there will be an escape hatch because you couldn't wave any kind of magic wand as a legislator and say "you can't sell software anymore if it's written in C++". The world would grind to a halt. So there will be an escape hatch, and there will be pressure. So as a company you have to look at how are you going to mitigate that risk going forward. And what's your plan going to be so that you can continue to sell products to the government. And how do you make sure that you're not opening up a competitive threat. If you've got a competitor that can say "well we're written entirely in Rust so we don't have to do the paperwork" that becomes a faster path. So you want to make sure that you're aware of those issues and that you've got a plan in place to mitigate them.
cbsmith 3y ago
"Consider the hoops one needs to jump through to make std::print work with a custom type when compared to the old stream operators." As an old timer, this kind of made me laugh. I remember when people found the old stream operators burdensome.
29athrowaway 3y ago
If C++ wants to continue evolving, it needs breaking changes. It needs to impose a migration duty to the user, but that is not going to happen. So it will die a death by entropy where noone can know the language.
- tempodox 3y ago
  > it needs breaking changes. Then nobody will use the new compiler because nobody wants to rewrite millions of LOC and introduce new bugs.
  - 29athrowaway 3y ago
    AI will do it one day.
    - layer8 3y ago
      Introduce new bugs, sure.
      - random_mutex 3y ago
        That's what will end the AI hype.
- eej71 3y ago
  I think the great challenge with breaking changes is demonstrating how other systems have done breaking changes with great success. They are quite rare. And no, the python2->python3 migration is not one of them. Neither is ip4->ip6.
  - Sankozi 3y ago
    The important part about breaking backward compatibility is allowing forward compatibility. Java is good in that regard, for each breaking change, you could still create a library that worked for Java N and Java N+1. It is possible to have a network supporting IPv4 and IPv6. I don't think the speed of migration is an issue. It is not a tremendous success but it is not a failure either. In Python forward compatibility was often impossible. The migration benefit was low and the cost was high. Python is a great example how not to break things. I am little surprised that whole language is still popular after such failure of leadership.
clibraries 3y ago
weird to throw in 3 pet libraries he is advocating for at the end
artagnon 3y ago
Honestly, everyone working with C++ sticks to a select subset of the language that they've chosen for their project, or the project they're contributing to. Nobody knows all of C++. Personally, I don't mind C++ forking out in different directions and accepting diverse proposals; while I wouldn't bother to use them myself, I realize that it may be useful to other people. C++ is an engineer's language, and it's ridiculous to imagine that we'd ever need a C++2.0 that cleans it up. Subjectively, you could say that some features are "ugly", but this is an evolutionary process, and there are bound to be vestigial features. Yes, there are memory safety issues, but in practice, these are isolated in very few places. Take a compiler like LLVM for instance: most developers are working on transforms or analyses, and they're exposed to zero manual memory management. Sure, the Pass Manager needs to build passes, and the IR needs to be allocated, but that's about all the manual memory management there is. Personally, I couldn't care less about standardized argv-parsing, as each project has its own set of complex requirements. There are JSON parsing libraries available for C++, and I don't see why it should be standardized. Faster hashing in std could be a low-priority feature, but projects like LLVM have their own optimized version of std data structures and algorithms. I suppose a module system could be useful; most C++ projects are built with CMake which is already very good at finding and linking dependencies. Personally, my biggest pain point is compile-times, but that's really an LLVM/Clang problem. Overall, the article doesn't seem to be written by someone who has a lot of experience with large C++ codebases.
- pcwalton 3y ago
  > Yes, there are memory safety issues, but in practice, these are isolated in very few places. Take a compiler like LLVM for instance: most developers are working on transforms or analyses, and they're exposed to zero manual memory management. It is really easy to get use-after-free in LLVM passes due to using eraseFromParent() instead of removeFromParent(), etc. As I recall, in some places the optimization code goes through really awkward patterns in order to keep track of the IR nodes that are dead to avoid UAF, none of which would be necessary if LLVM were written in a GC'd language. (Note: I'm not saying LLVM should be written in a GC'd language.)
  - pjmlp 3y ago
wavemode 3y ago
I agree with everything written here - C++ is never going to be Rust, or any other language, but it can at least become better than it is now, in some common-sense ways. In my view, C++'s biggest problem is its design-by-committee structure, leading to a lack of pragmatism - in other words, perfect is the enemy of good. Pragmatism is what you see when you look at the standard libraries of languages like Python and Java: are they perfect? Far from it. But they prioritize being at least good enough for a good amount of situations, over being perfect. Which ends up being far more useful for regular people. And being useful for regular people is what makes a programming language successful. But design by committee means if your proposal isn't perfect, it will get shot down. So the language remains bad for everyone's use cases, rather than at least becoming somewhat good for some people's use cases.
chris_wot 3y ago
I have seen that the biggest issue with C++ is that legacy C++ is quite hard to refactor to the new patterns. For example, I have been working on font substitution in LibreOffice, and I'd like to use a more functional style of programming, but I'm getting stuck because of an overuse of classes. I've been reading Functional Programming in C++ by Ivan Cukic and I'd like to adopt this - it does require a lot of refactoring of this massive codebase. Perhaps this is a massive, ancient codebase issue more than a C++ issue, though.
- andrewmcwatters 3y ago
  I think this is one place where you're totally working against the language. Edit: I don't know how you can arrive at this conclusion given the history of the language. The STL isn't the C++ standard library. I would love to discuss this more, but dang has limited and nerfed my account.
  - chris_wot 3y ago
    Not really. Look at the standard template library. It’s not really using classes with inheritance. It’s using non-member functions, often with iterators. Ironically I’ve just learned, however, that lambdas are actually anonymous classes! I’m currently up to the bit in yhe book I referred to before that explains how to do currying in C++. The more I read, the more I think I’m working against the code base than I am against C++. I’m actually very curious how ranges work, something the book talks about later.
    - chris_wot 3y ago
      Sorry, not STL, I meant the standard C++ library. Edit: send an email to news@ycombinator.com
samsquire 3y ago
I hope people don't throw out the effective and well-thought out parts with the problematic parts. It happened with Macromedia Flash and it happened with Microsoft's Visual Basic. The JVM and industry attitudes to Java. PHP. We have lost some good technology over time, please don't let us lose the good parts of C++.
- andrewmcwatters 3y ago
  For whatever reason, the software industry never learns this lesson. Maybe because people would rather move on to something new entirely and new entrants are not aware of what they're losing at all.
- bborud 3y ago
  I'm not sure this is best done by holding on to implementations of those ideas that have serious flaws. Yes, learning is slow, and most languages seem to start with a handful of ideas someone wants to realize and then ignoring a lot of the difficult stuff others took a long time to solve.
fl0ki 3y ago
> However, I don’t want to give the impression we should say no to all proposals. There are plenty of opportunities to improve our user’s lives through proposals. Here are a few concrete examples: [all 3 are just library additions that exist outside the standard already] This may not have been the intent, but the way I read it, it's saying that language evolution is now pointless and only library additions can be considered. That would be a pretty dire situation for C++ overall. Never mind that this means many language issues will never be fixed, it would also mean that implementations face the burden of yet more standard library additions which quickly fall behind external libraries because of the added burden of ABI lockin, and now multiplied by several vendors vs just one third party library.
einpoklum 3y ago
Kind of a weird paper. 1. It uses formalism to try to deny that there is some competition for brain-share and number-of-users among programming languages, or rather around the communities around programming languages. 2. It ignores how C++ has, multiple times, semi-reinvented itself rather than "being C++", spurred by features, idioms or use patterns in other languages, and even managed to mostly "eat their lunch", for better or worse (e.g. the D language). 3. A call for "aiming for coherence", while ignoring how it sometimes contradiction with other principles, such as: "What you don’t use, you don’t pay for" (the zero-overhead rule); and failure to argue even for a balance. 4. "In committee, we frequently spend time on things that only a small number of people care about." <- but these are sometimes extremely important things, relevant to many, and in the future perhaps most programmers; and a small number of people care about them because most people aren't aware of their current or future importance. This is especially poignant where those things will only become important if the committee adopts them, and otherwise can be argued retroactively to never have been worthy of any discussion. etc. etc.
lucidguppy 3y ago
The C++ community has some of the best brains around. Absolute geniuses. If C++ is ok with being a small language used by and for geniuses - I have no problem with that. If C++ wants to be popular - we need a breaking change between the world of 2023 and 1990 - they don't know what we know now. I like some parts of C++... it's too bad the "good language" is shackled to a mountain of razor blades.
- throwaway2037 3y ago
  What do you think about Carbon[1]? I am hopeful. [1] https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang
  - pjmlp 3y ago
    Not the OP, Carbon currently still doesn't have a working implementation, it is clearly a tool for Google to migrate away from C++ without rewriting the world, they are quite open that it isn't trying to be anything else, it is only an experiement, and it may even fail as an experiment. Carbon gets talked a lot by people that somehow miss the language goals.
nxobject 3y ago
TFA cites a much more satisfying since technically substantial distillation of "what C++ is", especially regarding technical goals and technical philosophy: the "Direction for ISO C++" document, 2022, by core members of the ISO C++ committee. [1] [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2000r4.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...
MathMonkeyMan 3y ago
In every job I've had so far, I've been writing C++ because the guy before me wrote C++. That's really all there is to it. What "C++" means depends on the project. Maybe that's why it's so hard for the standard -- they have to consider more than one project.
throwat2341 3y ago
C++ has major flaws that cannot be rectified without serious breaking changes. With that said, Herb has been experimenting with a new cpp frontend with sane defaults [1]. In my opinion, the world is on standby until Anders Hejlsberg feels like tackling a modern, next generation systems language. [1] https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
- HarHarVeryFunny 3y ago
  Herb Sutters' proposal is absolutely the right direction to go to reign C++ back into being a sane simpler language from the mess it has grown into. I doubt it'll ever happen though. It seems that in the eyes of most of corporate America's management, C++ is a legacy language, and should be replaced with Java (which tbh makes sense in many cases given that Java's tooling and libaries are better than those of C++). Other companies are looking at Rust as a successor to C++. Even if Herbs's work was completed and implemented by major compilers, it's hard to see much uptake - who's going to be approving porting legacy C++ code to a new modern C++, yet alone approving C++ for new projects? Maybe if there is a Sutter C++ successor, it should drop the "C++" name which carries legacy associations, and call itself something new. Present itself as C++ successor, even if it comes from a starting point of being 99% backwards compatible with modern (say C++11 or later) C++. Sounds superficial, but I bet it'd make a difference in perception!
bborud 3y ago
C++ isn't C++. It is every incarnation of the language, every language subset defined in a code standard (for a project or an organization), over decades. Sure you can write virgin code in C++ and choose some "modern" incarnation of the language or some subset thereof. But there exists billions of lines of legacy that most of us have to deal with. Daily or occasionally. Usually without the option of rewriting. Then there's the tooling. The horrific, antiquated build process which we try to automate with tools that just make things even more complex. The lack of a practical standard library that says "you know, those things you often have to do, we should actually offer those". It is neither helpful nor useful that C++ doesn't have room for HTTP, JSON, basic networking abstractions etc. I would not recommend a beginner learn C++ today. I'd recommend Rust or Go. Most people are going to be more productive AND produce more robust code in fewer years. One can be annoyed by that statement, but you would have an uphill battle claiming that it is wrong. I don't think C++ is worth the investment for a new programmer. Dealing with C++ just gets more complex the more changes we make to it and the more we evolve it. C++ isn't just one spec - it is the aggregate of all specs and practices that have existed because that's what you risk ending up working on in real life. It's a bit much history. From the perspective of the programmer I think it is a much better idea to put some energy behind a fresh start. And try to remember the mistakes that were made. Right now, for C++ developers, Rust looks like the closest thing to a fresh start. But it may be that Go is going to make a lot of C++ programmers a lot happier too since not all C++ code lives in constrained environments or actually has to deliver bare metal performance. I don't think the C++ community even wants C++ to turn into something that is comparable to Rust or Go. Doing that to C++ would require throwing things out and creating something very different.

C++ Should Be C++

134 points by steveklabnik 3y ago

fancyfredbot 3y ago

What is the proposed legislation referred to in this article?

nickm12 3y ago
I have not heard anything about legislation, but the NSA and CISA have been arguing for the industry to embrace memory safe languages: https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre... Even without legislation, I could imagine that the US government could try to enact software procurement rules that favor or require memory-safe implementations.

gavinray 3y ago

Honestly, the changes in C++ 20 and 23, plus the upcoming changes for 26 (looking at you, Concurrency TS v2) have so drastically improved the language it's almost like the ES5 -> ES6 evolution of JavaScript. I might be in the minority here, but I genuinely enjoy writing modern C++. My complaints are about it's dependency management story and lack of integrated, standardized tools for things like dependencies, testing, logging, etc.

JohnFen 3y ago
I don't know if you're in the minority or I am, but I find modern C++ to be borderline intolerable (and I've been programming mostly in C++ from before there were C++ compilers). I used to love C++ (and still do if we're talking about older standards), but the new stuff is just a baroque torture.
- eps 3y ago
  Aye, same here. I don't mond C++ evolving into some thing of its own beyond all recognition, but there is a distinct lack of modern "C with Classes" language. Basically, C on steroids. There are attempts at that, but none is perfect and/or has enough traction to be viable.
  - WanderPanda 3y ago
    I just want a C with templates (and function overloading)?
    - eps 3y ago
      "this" and virtual functions are pretty damn useful too.
  - CuriousCosmic 3y ago
    You can still have "C with Classes" in modern C++ if you really want that. Just set a style guide that limits your code to that. There's more viable coding styles in C++ than I can honestly even bother to count. There's absolutely no reason to limit the language to one specific coding style when doing so would alienate large groups of users and you can set those limits yourself on your project.
    - JohnFen 3y ago
      This is what I do for my own projects, but it's not a viable thing to do with my work projects since I don't set the style.
    - eps 3y ago
      Yeah, I know and that's how I've been using it for the past decade, but it's not that simple. The language keeps changing and this forces adding cruft to the code if one wants to use newer compilers. For example, there are cases where the existence of move semantics necessitates adding some boilerplate when working with STL containers. There's no functional reason for it, just something to please the compiler.
  - 3y ago
Night_Thastus 3y ago
Anything C++11 forward is alright with me, though 17 introduces some very nice conveniences like <execution>, <filesystem> and most critically <optional>. Honorable mention to std::clamp too.
- ska 3y ago
  > Honorable mention to std::clamp too. One shudders to think how many times variations of that template have been written in house.
  - Night_Thastus 3y ago
    Heck, I find so many cases where std::min and std::max could be used as well.
- frfl 3y ago
  23 introduced <expected> (result/either) as well
- spacechild1 3y ago
  I would like to add: - structured bindings - auto parameters in lambdas - init statements in if and switch clauses - template argument deduction for constructors
TillE 3y ago
You're absolutely not in the minority, old C++ was awful and there have been so many improvements to the language and standard library to help write simpler, clearer code. I was just recently appreciating the if statement with an initializer in C++17, which helps me express exactly what I want for variable scope in one line instead of multiple awkward ones.

oldpersonintx 3y ago

this feels defeatist c++ is with us for the near future, it needs an evolutionary path that provides a sane path forward why not break with the past? anyone needing to compile c++11 can find the tools and still use them, they can live in the past as long as they like just getting dependency/build management and integrated testing would be huge and really a small ask given what is happening in other tools its crazy that you still can't make sane use of things like modules, even if you fully commit to "modern" c++

pphysch 3y ago
Lack of modules support is the biggest thing keeping me from doing more c++ greenfield. So much friction in managing a pointless interface<->implementation layer.
- frfl 3y ago
  I'm not well versed in C++ best practices, but unless it's a non-option for your situation, have you considered single file headers or perhaps even a unity build[1] approach? Of course, both are just workarounds for proper module support and have their drawbacks and limitations. [1]: https://en.wikipedia.org/wiki/Unity_build https://en.wikipedia.org/wiki/Unity_build
- u_name 3y ago
  Yes! Proper modules support would give c++ a well needed boost (no pun intended!). msvc is kinda there, but it breaks here and there with intellisense.
Night_Thastus 3y ago
This is the never-ending problem with programming languages. If you make big breaking changes, the community suffers - even if the changes are very well intentioned. Look at the long tail of Python 2 vs 3 issues. If it happens once it's not so bad, but the older the community and the greater the size of its existing ecosystem - the more that pain becomes. Rust, from what I've seen, understands this issue.

EdSchouten 3y ago

> What is much less prevalent is a demand from average C++ users for memory safety features; they’re much more concerned about compilation speed. When most C++ developers haven’t adopted tools like Coverity and C++ core guidelines checkers, it is hard to claim that memory safety features substantially improve their lives at least from their point of view. I don’t really agree with this. There’s also a group of developers that want more safety, but don’t feel like setting up (or in the case of Coverity purchasing) additional tooling. Some people just want a decent out of the box experience.

moffkalast 3y ago
I think it's less about not wanting memory safety and more that compilation speeds are so time-wastingly abysmal that it's a few orders of magnitude more important to address. The whole deal with interpreted languages was to avoid sitting there for a few minutes every time you make a god damn one letter change, with the unfortunate but usually acceptable trade-off of some execution speed.
- mxmlnkn 3y ago
  And the additional trade-off that some bugs are only noticed at runtime when that particular line is executed while it could have been noticed by the compiler of a strongly typed language. Pytype helps but at this point you have a static analyzer that potentially runs as slow as a compiler without the additional performance benefit.
  - moffkalast 3y ago
    Idk as long as you can develop at speed I don't see why a static analyser that's a few times slower than compiling couldn't run on the latest commit overnight? More as a sonarqube type thing I suppose.
  - josephg 3y ago
    There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.

diath 3y ago

Nevermind the language itself, we need a way to pull compilers and project dependencies, pinned to their specific versions, with a single, ergonomic tool. vcpkg seemed really promising but the fact that they didn't start with library versioning from the get go was a very stupid decision, and nowadays versions are pinned to specific commit hashes rather than actual dependency versions, and libraries that weren't previously versioned cannot be fetched if your project relies on an older pre-vcpkg version of a library and cannot be upgraded for one reason or another. These days I find myself struggling more and more with proper dev setup where I have an up-to-date compiler on any machine I want to build the code along with its libraries without running into a rabbit hole of compiler and library issues.

bqmjjx0kac 3y ago
Have you looked into Bazel? https://bazel.build/start/cpp https://bazel.build/start/cpp It's not always easy to use, but the focus on reproducible builds and caching is really nice. Edit: I guess it doesn't fetch a specific compiler for you by default, but you could probably ship your toolchain somewhere and pin it in your WORKSPACE file.
- steveklabnik 3y ago
  Don't forget buck2 as well.
andrewmcwatters 3y ago
vcpkg was dead in the water because they altered source packages. Completely unacceptable in many situations.
- kimixa 3y ago
  I also find vcpkg extremely fragile. Not in that pinning versions or the APIs or the actual contents of the packages we rely on, so much that every time we update a (rather small) set of dependencies there's nearly always some weirdness around vcpkg itself or the builds. Just the last week we updated to a newer tag and building openssl failed setting up the nasm build dependency, claiming it already existed. Which it did - there was a "nasm" folder in the tools directory it was trying to install it in, from the last time it was installed presumably and somehow got it's internal state messed up. But this caused a fatal error. I eventually worked around it by deleting the nasm directory from every build machine and letting it reinstall exactly the same package again. But the time before there was also a "random" build error, claiming that xz wasn't installed, despite the log showing it was just installed as a dependency in the line above. I guess this was fixed upstream, as the "workaround" was to use a tag from a month or so previous, but now seems to be fixed. Perhaps I'm using it wrong, perhaps you should "always" completely blast away the global vcpkg folder (and any vcpkg stuff cached in build directories from it's cmake integration) every time you touch it. But it's still time and effort for something that probably should be seamless.

lisper 3y ago

> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. No, that is false. It is akin to arguing that Christianity must be true because 2.4 billion Christians can't be wrong. The fallacy is easy to see because the argument can be applied equally to the world's 1.9 billion Muslims and 1.2 billion Hindus and 500 million Buddhists, etc. And yet these groups hold mutually-exclusive positions and so at least N-1 of them must be wrong. Humans are social animals. With only a few exceptions, we tend to conform to the group. That tends to make us get stuck in very deep ruts. "Everyone is doing it" is absolutely no indication that "it" is a good idea. [UPDATE] A lot of people seem to be missing the point here, so I feel the need to clarify: I'm not saying C++ is analogous to a relgion. I'm using the exclusivity of religious belief just as a short-cut to show that it is possible for large groups of people to hold false beliefs without getting into the weeds of which of those beliefs are actually false. The point is not that C++ is analogous to a religion, just that "adoption by millions" is not a valid argument for its merits. [UPDATE2] I am also not saying that religion has no value beyond the truth of its objective claims. I am only saying that (some of) the world's major religions do make objective claims, some of those claims are mutually exclusive, and so some of them must be objectively false, and therefore it is manifestly true that large groups of people can hold objectively false beliefs, and therefore the fact that large groups of people hold a position is not evidence that that position is objectively true. Being "fit as a general purpose programming language" is an objective claim.

paulddraper 3y ago
Awful analogy. C++'s fitness as a general-purpose programming language is not an exclusive assertion.
- rcthompson 3y ago
  That's not the point. The point is that "N people can't be wrong" is not a valid argument for any value of N.
  - Rexxar 3y ago

galkk 3y ago

I like that this doc at least says that C++ is unergonomic. I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations. And when you look into C++ libraries/stdlib, they often look like they're written in another language entirely. This is not normal.

professoretc 3y ago
> I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations. Why would that be true? When you write a library, you are writing code to cover all possible uses; everything within the scope of your library should at least be considered, even if you personally have no need of that particular bit of functionality. But when you write a program it only has to do one thing, so of course it's going to be simpler. To me, it seems obvious that (good) library code will be very different from (good) application code. (I've used libraries that were written like applications, but they were bad libraries; I was constantly fighting the fact that the library author wrote only for their own use-case, and didn't consider any other.)
- josephg 3y ago
  I hear you. But I’ve also learned a lot about how to write idiomatic rust from scrolling through rust’s standard library. You’re right - because it’s written to support lots of programs, it sure is packed with a lot of functions I’ll probably never use. But it’s still quite beautiful and readable. Much more so than C++. Here’s std::vec: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html https://doc.rust-lang.org/src/alloc/vec/mod.rs.html I tried to read C++’s vec class when I was learning C++ and I was confused and lost. I agree with the GP post - it feels like another language.
  - ativzzz 3y ago
    I'm not very familiar with rust, but isn't the point to mostly avoid `unsafe` and write safe code? Strange that basic std vec functions like insert and remove call `unsafe` - isn't this an example where you don't want to be like the std lib?

blt 3y ago

I feel the C++ committee saw the major quality-of-life improvements from C++11 and convinced themselves that Python's ergonomics with templated C++'s speed was possible. I won't say it's impossible, but the backwards compatibility sure seems like too much weight.

KerrAvon 3y ago

Is this a response to some specific set of proposals? I know there's been a lot of general angst / misunderstanding over C++ memory safety.

tempodox 3y ago
What's to misunderstand? There is no memory safety in C++.
IshKebab 3y ago
It's a response to Rust. Rust is significantly better than C++, and most importantly it's the first language that could actually replace C++ for the things C++ is generally used for. I guess the C++ community is coming to terms with not being the top dog of "zero-cost abstraction" languages anymore. Really I think it's too late for C++. They had literal decades to fix very basic flaws, and they just haven't done it. Accidental octal literals. Case fall-through. Missing `return`s. Accidental string literal addition. The whole module system mess. They focused way too much on adding complex features and not at all on fixing footguns. As a result C++ is painful and dangerous. Too late to fix IMO.

CoolGuySteve 3y ago

> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. Everywhere in the std lib you can see compromises that require rewriting substantial portions for any real time application. Things like: shared_ptr eagerly using atomics whenever possible; std::string allocating; the lack of built-in faster std::allocator replacements like bump allocators, memory pools, etc; no lockless and wait free concurrency primitives; no architecture-aware thread pools or even architecture descriptions; no IPC primitives; etc. Considering how many C++ developers are working on things like games, high performance server applications, databases, and operating systems, it's just bizarre how inappropriate the standard headers are for these tasks. Even something trivial like casting bytes off the wire to a packed struct is an exercise in frustration due to aliasing rules that should have been encoded in the type system and invisible to the user.

zozbot234 3y ago
Why does this have to be part of the standard library? Isn't that the whole point of Boost, that one is not limited to what's in std?
- CoolGuySteve 3y ago
  It depends on the contributors, but boost also almost always fails to consider performance implications. For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time. The alignment of incentives between these library authors and people that use C++ for high performance applications is just off.
  - gumby 3y ago
    > For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time. It’s also the opposite: a place where possible candidates for the standard get tried out first. But like you, I rarely use it.
- 3y ago

weinzierl 3y ago

"upcoming anti-C++ safety regulations" Is this a thing really or just FUD?

omoikane 3y ago
Probably related to things like these: https://news.ycombinator.com/item?id=33560227 https://news.ycombinator.com/item?id=33560227 - NSA urges orgs to use memory-safe programming languages
steveklabnik 3y ago
What is a real thing: various government organizations arguing that projects should move towards memory safe languages. What is not a real thing: regulations requiring such. Some think regulations may come, others don't.
unstruktured 3y ago
Not familiar with said regulations, but Ada was a good example of not using C++ for these very reasons in a military context.
barryrandall 3y ago
It's both and neither. Some countries are considering legislation to require "memory-safe" tooling for "critical" workloads, and C++ has never been placed on the "memory-safe tooling" list.
- steveklabnik 3y ago
  Which countries? Can you share the reporting on this legislation? I’d be very interested.
  - dtolnay 3y ago
    The best forecast I know is Sean Parent's on ADSP episode 160. [0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical components will get rewritten into Rust or another memory-safe language. [0:24:28] CH: When you say "pending legislation", is that a nod to some pending legislation that you actually know is on the horizon? Or just anticipating that it's going to happen at some point? [0:24:38] SP: Oh yeah, no. There are two bills (sorry I don't have...) [0:24:44] CH: It's all right, we'll find them and link them in the show notes afterward. [0:24:48] SP: Yeah, I can hunt down the links. The one in the U.S. that's pending basically says that the Department of Defense is going to within 270 days of the bill passing (and it's a funding bill which means it will probably pass late this year - early next year) that the Department of Defense will establish guidelines around safety and security including memory safety for software products purchased by Department of Defense. The E.U. has a similar wording in a bill that's slowly winding its way through their channels. I don't have insight into when that will pass. The U.S. one will almost certainly pass here within a month or two. [0:25:43] CH: Oh. Wow. [0:25:44] SP: There's a long way between having a bill pass that says almost a year later they have to establish a plan for what they're going to do, right. So it's not hard legislation in any way. But I view this-- I can send you a link. There was a podcast I listened to recently on macOS folklore. [...] It's talking about how in the early '90s there was a somewhat similar round of legislation that went around around POSIX compliance. Basically the Department of Defense decided that in order to have portable software, every operating system that they purchased had to have POSIX compliance. And there was a roadmap put into place. That's why Apple pursued building their own UNIX which was A/UX and eventually partnered with IBM to do AIX. And Microsoft in the same timeframe had a big push to get POSIX compliance in Windows OS. The thinking was eventually in order to sell to the government your operating system it would require POSIX compliance. What actually happened, if you wanted to buy just traditional Macintosh operating system you would just say "well I require Photoshop or pick-your-application and there is no alternative that runs under UNIX so therefore I need an exception to buy macOS" and it was extra paperwork but it got signed off on. So really never materialized into hard restrictions on sales of non-POSIX-compliant OSes. I expect the safety legislation to take somewhat the same route, which is, there will be pressure to write more software in memory-safe languages. When you don't write software in memory-safe languages there is going to be more pressure for you to document what your process is to mitigate the risks. And this is initially all in the realm of government sales, although there is some discussion in both the E.U. legislation and on the U.S. side of extending this to a consumer safety issue. But there will be an escape hatch because you couldn't wave any kind of magic wand as a legislator and say "you can't sell software anymore if it's written in C++". The world would grind to a halt. So there will be an escape hatch, and there will be pressure. So as a company you have to look at how are you going to mitigate that risk going forward. And what's your plan going to be so that you can continue to sell products to the government. And how do you make sure that you're not opening up a competitive threat. If you've got a competitor that can say "well we're written entirely in Rust so we don't have to do the paperwork" that becomes a faster path. So you want to make sure that you're aware of those issues and that you've got a plan in place to mitigate them.

cbsmith 3y ago

"Consider the hoops one needs to jump through to make std::print work with a custom type when compared to the old stream operators." As an old timer, this kind of made me laugh. I remember when people found the old stream operators burdensome.

29athrowaway 3y ago

If C++ wants to continue evolving, it needs breaking changes. It needs to impose a migration duty to the user, but that is not going to happen. So it will die a death by entropy where noone can know the language.

tempodox 3y ago
> it needs breaking changes. Then nobody will use the new compiler because nobody wants to rewrite millions of LOC and introduce new bugs.
- 29athrowaway 3y ago
  AI will do it one day.
  - layer8 3y ago
    Introduce new bugs, sure.
    - random_mutex 3y ago
      That's what will end the AI hype.
eej71 3y ago
I think the great challenge with breaking changes is demonstrating how other systems have done breaking changes with great success. They are quite rare. And no, the python2->python3 migration is not one of them. Neither is ip4->ip6.
- Sankozi 3y ago
  The important part about breaking backward compatibility is allowing forward compatibility. Java is good in that regard, for each breaking change, you could still create a library that worked for Java N and Java N+1. It is possible to have a network supporting IPv4 and IPv6. I don't think the speed of migration is an issue. It is not a tremendous success but it is not a failure either. In Python forward compatibility was often impossible. The migration benefit was low and the cost was high. Python is a great example how not to break things. I am little surprised that whole language is still popular after such failure of leadership.

clibraries 3y ago

weird to throw in 3 pet libraries he is advocating for at the end

artagnon 3y ago

Honestly, everyone working with C++ sticks to a select subset of the language that they've chosen for their project, or the project they're contributing to. Nobody knows all of C++. Personally, I don't mind C++ forking out in different directions and accepting diverse proposals; while I wouldn't bother to use them myself, I realize that it may be useful to other people. C++ is an engineer's language, and it's ridiculous to imagine that we'd ever need a C++2.0 that cleans it up. Subjectively, you could say that some features are "ugly", but this is an evolutionary process, and there are bound to be vestigial features. Yes, there are memory safety issues, but in practice, these are isolated in very few places. Take a compiler like LLVM for instance: most developers are working on transforms or analyses, and they're exposed to zero manual memory management. Sure, the Pass Manager needs to build passes, and the IR needs to be allocated, but that's about all the manual memory management there is. Personally, I couldn't care less about standardized argv-parsing, as each project has its own set of complex requirements. There are JSON parsing libraries available for C++, and I don't see why it should be standardized. Faster hashing in std could be a low-priority feature, but projects like LLVM have their own optimized version of std data structures and algorithms. I suppose a module system could be useful; most C++ projects are built with CMake which is already very good at finding and linking dependencies. Personally, my biggest pain point is compile-times, but that's really an LLVM/Clang problem. Overall, the article doesn't seem to be written by someone who has a lot of experience with large C++ codebases.

pcwalton 3y ago
> Yes, there are memory safety issues, but in practice, these are isolated in very few places. Take a compiler like LLVM for instance: most developers are working on transforms or analyses, and they're exposed to zero manual memory management. It is really easy to get use-after-free in LLVM passes due to using eraseFromParent() instead of removeFromParent(), etc. As I recall, in some places the optimization code goes through really awkward patterns in order to keep track of the IR nodes that are dead to avoid UAF, none of which would be necessary if LLVM were written in a GC'd language. (Note: I'm not saying LLVM should be written in a GC'd language.)
- pjmlp 3y ago

wavemode 3y ago

I agree with everything written here - C++ is never going to be Rust, or any other language, but it can at least become better than it is now, in some common-sense ways. In my view, C++'s biggest problem is its design-by-committee structure, leading to a lack of pragmatism - in other words, perfect is the enemy of good. Pragmatism is what you see when you look at the standard libraries of languages like Python and Java: are they perfect? Far from it. But they prioritize being at least good enough for a good amount of situations, over being perfect. Which ends up being far more useful for regular people. And being useful for regular people is what makes a programming language successful. But design by committee means if your proposal isn't perfect, it will get shot down. So the language remains bad for everyone's use cases, rather than at least becoming somewhat good for some people's use cases.

chris_wot 3y ago

I have seen that the biggest issue with C++ is that legacy C++ is quite hard to refactor to the new patterns. For example, I have been working on font substitution in LibreOffice, and I'd like to use a more functional style of programming, but I'm getting stuck because of an overuse of classes. I've been reading Functional Programming in C++ by Ivan Cukic and I'd like to adopt this - it does require a lot of refactoring of this massive codebase. Perhaps this is a massive, ancient codebase issue more than a C++ issue, though.

andrewmcwatters 3y ago
I think this is one place where you're totally working against the language. Edit: I don't know how you can arrive at this conclusion given the history of the language. The STL isn't the C++ standard library. I would love to discuss this more, but dang has limited and nerfed my account.
- chris_wot 3y ago
  Not really. Look at the standard template library. It’s not really using classes with inheritance. It’s using non-member functions, often with iterators. Ironically I’ve just learned, however, that lambdas are actually anonymous classes! I’m currently up to the bit in yhe book I referred to before that explains how to do currying in C++. The more I read, the more I think I’m working against the code base than I am against C++. I’m actually very curious how ranges work, something the book talks about later.
  - chris_wot 3y ago
    Sorry, not STL, I meant the standard C++ library. Edit: send an email to news@ycombinator.com

samsquire 3y ago

I hope people don't throw out the effective and well-thought out parts with the problematic parts. It happened with Macromedia Flash and it happened with Microsoft's Visual Basic. The JVM and industry attitudes to Java. PHP. We have lost some good technology over time, please don't let us lose the good parts of C++.

andrewmcwatters 3y ago
For whatever reason, the software industry never learns this lesson. Maybe because people would rather move on to something new entirely and new entrants are not aware of what they're losing at all.
bborud 3y ago
I'm not sure this is best done by holding on to implementations of those ideas that have serious flaws. Yes, learning is slow, and most languages seem to start with a handful of ideas someone wants to realize and then ignoring a lot of the difficult stuff others took a long time to solve.

fl0ki 3y ago

> However, I don’t want to give the impression we should say no to all proposals. There are plenty of opportunities to improve our user’s lives through proposals. Here are a few concrete examples: [all 3 are just library additions that exist outside the standard already] This may not have been the intent, but the way I read it, it's saying that language evolution is now pointless and only library additions can be considered. That would be a pretty dire situation for C++ overall. Never mind that this means many language issues will never be fixed, it would also mean that implementations face the burden of yet more standard library additions which quickly fall behind external libraries because of the added burden of ABI lockin, and now multiplied by several vendors vs just one third party library.

einpoklum 3y ago

Kind of a weird paper. 1. It uses formalism to try to deny that there is some competition for brain-share and number-of-users among programming languages, or rather around the communities around programming languages. 2. It ignores how C++ has, multiple times, semi-reinvented itself rather than "being C++", spurred by features, idioms or use patterns in other languages, and even managed to mostly "eat their lunch", for better or worse (e.g. the D language). 3. A call for "aiming for coherence", while ignoring how it sometimes contradiction with other principles, such as: "What you don’t use, you don’t pay for" (the zero-overhead rule); and failure to argue even for a balance. 4. "In committee, we frequently spend time on things that only a small number of people care about." <- but these are sometimes extremely important things, relevant to many, and in the future perhaps most programmers; and a small number of people care about them because most people aren't aware of their current or future importance. This is especially poignant where those things will only become important if the committee adopts them, and otherwise can be argued retroactively to never have been worthy of any discussion. etc. etc.

lucidguppy 3y ago

The C++ community has some of the best brains around. Absolute geniuses. If C++ is ok with being a small language used by and for geniuses - I have no problem with that. If C++ wants to be popular - we need a breaking change between the world of 2023 and 1990 - they don't know what we know now. I like some parts of C++... it's too bad the "good language" is shackled to a mountain of razor blades.

throwaway2037 3y ago
What do you think about Carbon[1]? I am hopeful. [1] https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang
- pjmlp 3y ago
  Not the OP, Carbon currently still doesn't have a working implementation, it is clearly a tool for Google to migrate away from C++ without rewriting the world, they are quite open that it isn't trying to be anything else, it is only an experiement, and it may even fail as an experiment. Carbon gets talked a lot by people that somehow miss the language goals.

nxobject 3y ago

TFA cites a much more satisfying since technically substantial distillation of "what C++ is", especially regarding technical goals and technical philosophy: the "Direction for ISO C++" document, 2022, by core members of the ISO C++ committee. [1] [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2000r4.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

MathMonkeyMan 3y ago

In every job I've had so far, I've been writing C++ because the guy before me wrote C++. That's really all there is to it. What "C++" means depends on the project. Maybe that's why it's so hard for the standard -- they have to consider more than one project.

throwat2341 3y ago

C++ has major flaws that cannot be rectified without serious breaking changes. With that said, Herb has been experimenting with a new cpp frontend with sane defaults [1]. In my opinion, the world is on standby until Anders Hejlsberg feels like tackling a modern, next generation systems language. [1] https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront

HarHarVeryFunny 3y ago
Herb Sutters' proposal is absolutely the right direction to go to reign C++ back into being a sane simpler language from the mess it has grown into. I doubt it'll ever happen though. It seems that in the eyes of most of corporate America's management, C++ is a legacy language, and should be replaced with Java (which tbh makes sense in many cases given that Java's tooling and libaries are better than those of C++). Other companies are looking at Rust as a successor to C++. Even if Herbs's work was completed and implemented by major compilers, it's hard to see much uptake - who's going to be approving porting legacy C++ code to a new modern C++, yet alone approving C++ for new projects? Maybe if there is a Sutter C++ successor, it should drop the "C++" name which carries legacy associations, and call itself something new. Present itself as C++ successor, even if it comes from a starting point of being 99% backwards compatible with modern (say C++11 or later) C++. Sounds superficial, but I bet it'd make a difference in perception!

bborud 3y ago

C++ isn't C++. It is every incarnation of the language, every language subset defined in a code standard (for a project or an organization), over decades. Sure you can write virgin code in C++ and choose some "modern" incarnation of the language or some subset thereof. But there exists billions of lines of legacy that most of us have to deal with. Daily or occasionally. Usually without the option of rewriting. Then there's the tooling. The horrific, antiquated build process which we try to automate with tools that just make things even more complex. The lack of a practical standard library that says "you know, those things you often have to do, we should actually offer those". It is neither helpful nor useful that C++ doesn't have room for HTTP, JSON, basic networking abstractions etc. I would not recommend a beginner learn C++ today. I'd recommend Rust or Go. Most people are going to be more productive AND produce more robust code in fewer years. One can be annoyed by that statement, but you would have an uphill battle claiming that it is wrong. I don't think C++ is worth the investment for a new programmer. Dealing with C++ just gets more complex the more changes we make to it and the more we evolve it. C++ isn't just one spec - it is the aggregate of all specs and practices that have existed because that's what you risk ending up working on in real life. It's a bit much history. From the perspective of the programmer I think it is a much better idea to put some energy behind a fresh start. And try to remember the mistakes that were made. Right now, for C++ developers, Rust looks like the closest thing to a fresh start. But it may be that Go is going to make a lot of C++ programmers a lot happier too since not all C++ code lives in constrained environments or actually has to deliver bare metal performance. I don't think the C++ community even wants C++ to turn into something that is comparable to Rust or Go. Doing that to C++ would require throwing things out and creating something very different.