35 ms·

C++20, How Hard Could It Be

330 points by pyler 4y ago

oxff 4y ago
Writing Chromium grade C++ seems like a hard job with all these extrinsic rules and regulations to make it work
- meibo 4y ago
  You'll see these kind of rules at every place that cares about their C++ codebase. It's just not a language like Java, C# or JS where you can throw stuff at the wall and it'll probably work out.
  - otabdeveloper4 4y ago
    > Java, C# Maybe. > JS Hell no. "Frameworks" like React or Vue exist solely for the purpose of retaining developer sanity in the face of unregulated JS code.
  - speedgoose 4y ago
    Anyone serious with TypeScript/JavaScript has many Eslint rules to keep the codebase sain.
    - white_dragon88 4y ago
      [dead]
  - pjmlp 4y ago
    Even for Java, C# and JS we do enforce such kind of rules, e.g. https://sonarqube.org https://sonarqube.org
amelius 4y ago
I stopped using C++ after lambdas were introduced (10 years ago or so?) Is there anything I can read to get up to date quickly?
- smhaziq 4y ago
  https://learn.microsoft.com/en-us/cpp/cpp/welcome-back-to-cpp-modern-cpp?view=msvc-170 https://learn.microsoft.com/en-us/cpp/cpp/welcome-back-to-cp...
- stefanos82 4y ago
  I would suggest to go through https://github.com/AnthonyCalandra/modern-cpp-features https://github.com/AnthonyCalandra/modern-cpp-features ; it's quite clean.
  - kristopolous 4y ago
    Broken link
    - pivo 4y ago
      Remove the trailing semicolon https://github.com/AnthonyCalandra/modern-cpp-features https://github.com/AnthonyCalandra/modern-cpp-features
- pjmlp 4y ago
  Bjarne's "Tour of C++", 3rd edition.
diceduckmonk 4y ago
Is there a case for or against incrementally adopting Rust ?
- glandium 4y ago
  They are experimenting https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rust-toolchain.md https://chromium.googlesource.com/chromium/src/+/refs/heads/...
  - Existenceblinks 4y ago
    Is there any common module that can be shared amongst browser engines? I can feel though it sounds hard to extract these common stuff into .. "browser engine common core"? (e.g. https://github.com/SerenityOS/serenity/tree/master/Userland/Libraries/LibWeb https://github.com/SerenityOS/serenity/tree/master/Userland/...). That would be nice for next gen browser invention.
    - sbdncuvh 4y ago
    - hi_herbert 4y ago
      You can find some module candidates here https://github.com/servo/servo/issues/24026#issue-483508434 https://github.com/servo/servo/issues/24026#issue-483508434 The one that make the most economic sense would be for mozilla to drop spidermonkey and make v8 faster instead
- izacus 4y ago
  Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?
  - otabdeveloper4 4y ago
    Don't worry your little brain about these silly things. Programming is hard, let's go (language) shopping instead!
pornel 4y ago
Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.
- forgotpwd16 4y ago
  It doesn't cause problems as in old things don't work as in it takes time to get advantage of newly introduced ones and replace anything considered deprecated (edit: and rename variables clashing with new keywords).
- TonyTrapp 4y ago
  From what I can gather, a majority of the problems reported there are new compiler warnings being triggered. Especially if you enable all compiler warnings to catch potential defects, any upgrade to a new compiler version will typically introduce a ton of new warnings that you have to work around. Edit: There are also quite a few deprecation warnings, which are also not errors per se, but nevertheless you'd want to avoid using deprecated stuff of course.
- IshKebab 4y ago
  It generally does although they have made technically breaking changes in the past (e.g. `auto`). This is the first release I've used where they broke something in actual code I use because of the comparison operator changes. However it was easy to fix and actually it was because whoever wrote it did it wrong. Google also found a breakage that was hiding a bug. So maybe their new stance is "only break incorrect code"? I dunno. I feel like a small amount of breakage is reasonable anyway. Breaking change absolutionists are generally just being dogmatic, and haven't really thought through what zero breaking changes really implies. E.g. in languages with introspection it technically means you can't change anything.
  - pjmlp 4y ago
    They also broke the code of the few users that made use of exception specifications.
- pjmlp 4y ago
dureuill 4y ago
As expected modules are relegated to some later time ("will be its own experiment")
- pjmlp 4y ago
  Thanks clang lagging behind ISO C++, you can use them today on Visual Studio 2022.
  - mike_hock 4y ago
    Can't blame them. Modules are Microsoft sabotaging the standard so they can be the only conforming implementation, just like with the Office .doc format. Modules are unimplementable shite. They would be great if this was the first iteration of the language, but they're a nightmare to fit into the existing ecosystem. If they get support in open source compilers, we can look forward to at least one or two decades of a mixed modules/headers mess in open source projects.
    - pjmlp 4y ago
      Yet, somehow the GCC folks manage to keep improving their modules support, slow and steady. If they were unimplementable, there wouldn't exist already two major C++ compilers supporting them to some degree. It is only clang with their module maps pseudo concept that keeps lagging, that and plenty of other C++20 features.
      - mike_hock 4y ago
        Implementable by compilers, sure. Implementable by the ecosystem at large, yes, over the course of several decades. Edit: Also, module support better be 100% binary compatible between GCC and Clang, or it's worse than complete garbage.
        pjmlp 4y ago
        As if you could expect any kind of ABI compatibility between GCC and clang binary libraries today, and apparently it doesn't make them a complete garbage, go figure.
khoobid_shoma 4y ago
It's easier to say goodbye C++!
- speedgoose 4y ago
  A full rewrite seems extremely expensive and long. I’m afraid C++ isn’t going anywhere in our lifetime.
  - Kwpolska 4y ago
    C++ can stay, but people can make a decision not to use it for anything and not to take any jobs involving C++ (or other systems/bare-metal-ish languages).
- pjmlp 4y ago
  C is 10 years younger than COBOL, C++ is 20 years younger than COBOL, COBOL is still around.
- krater23 4y ago
  It's more easy to just don't adopt the new standard.
- butterisgood 4y ago
  I've written a fair amount of C++ in my day, and this seems totally unacceptable to me. Also my opinion seems unpopular on this topic, so I suspect some group of people that really want to get behind C++ don't like that kind of talk. Whatever though. Rust and other newer languages are kind of giving the spaces C++ works well in a run for its money and in other ways just completely blowing it out of the water in my opinion. It might be time to look at D again too.
butterisgood 4y ago
Damn. May as well have used a language that isn’t released yet like Zig. That’s a ton of problems.
- TinkersW 4y ago
  Um no. When I upgraded it was a few hours of work at most, for Google since its code base is extremely large maybe a few days to weeks.
  - Matumio 4y ago
    Probably no big issue for a small to medium codebase. But I doubt the "just a few days" estimate for something as big as a web-browser. If I read correctly they even found use-after-move bugs during the process.
    - TinkersW 4y ago
      The use after move existed prior, just wasn't moving even though they had written move. It is also written in a way that a linter should be able to detect if you disallow use after move. https://source.chromium.org/chromium/chromium/src/+/main:components/services/storage/indexed_db/locks/disjoint_range_lock_manager.cc;l=136;drc=2705e1173e88110a9778b88a1c3e1be8d103f7e9 https://source.chromium.org/chromium/chromium/src/+/main:com...
      - pkasting 4y ago
        It's surprisingly hard to detect these sorts of cases reliably; we have a request out to the clang-tidy folks to add some improved detection of use-after-move there.
  - pkasting 4y ago
    Took a couple of months actually, but it's mostly complete now and we're starting to throw the switches.
- ninepoints 4y ago
mrazomor 4y ago
Very useful presentation. Full of details, but easy to consume. On voices against stripped down C++ (via code style): I find it working great in practice. Makes the codebase manageable, and keeps people away from using unnecessary complex language features (imagine Java code heavy with streams or reflection, or Python code that resolves most of dependencies at runtime, javascript full of eval(), etc.). Switching to a new language is half-baked plan.
- hi_herbert 4y ago
  Ad-hoc black or white bans are very retrograde and costly for tje most part and usually stem from purity thinking. Case in point reflection in Java is a godsend. I use it very rarely because it'd uses only comes for very specific needs but when I use it, the alternative either doed not exist or usually would be much more uglier. As for streams well it's just regular functors (map, filter) they are used in every language and are very useful. Now I agree about two things: 1) the stream api is a bit (not that much though) verbose, which significantly contrast with Kotlin. Although e.g .toList() helps 2) yes develpers especially junior ones are eager to abuse functors in an unreadable mess. When there is complexity using loops is usually more readable. Streams however are very fit for regular ETL that represents ~70% of code for most simple apps. The pinnacle of complexity would be e.g. Reactive streams such as rxjava. I agree python dependencies are a worldwide shame and eval() is very niche (but again should not be universality banned assuming good developers, maybe though one could conditionally ban it aka it would trigger a lint during code review that would need explicit validation. As for the topic at hands, google style bans are insane e.g. No Exceptions lol
  - f1shy 4y ago
    I agree with this comment, and cannot understand why is downvoted. I would like the one that downvoted comments on why. My thinking, more or less in line with the comment is: instead of investing energy, time and resources in writing laws of what is allowed and what no (often without rationale). Use that time, effort and energy in educating developers, so that, if those prohibitions are really sensible, they will anyway refrain from doing that. You get the benefit of not having to change the bans. By doing regular code reviews, you can detect ill formed code, and discuss with the developers. Maybe some developer has something to teach to the "big experts" who write those documents?
pjmlp 4y ago
It is so ironic, that now that Apple and Google decided to focus on their own language stacks, the C and C++ compiler vendors that profit from clang's license aren't that keen in making the upstream work for catching up with ISO C++. Thus making the once famous clang having an honorable third place in ISO C++ compliancy. Seeing this from a Google team makes it even more ironic.
- otabdeveloper4 4y ago
  gcc is better than clang on every metric. Sorry, it's the facts. ¯\_(ツ)_/¯
  - spoiler 4y ago
    I've always preferred clang for its better lints, and friendlier error messages (sans some decrepit parts around templates that are equally horrendous everywhere)... And theoretically clang has better ASM output in some cases I say theoretically, because it's been shown that GCC's "worse" ASM performs better; I'm not really an architecture aficionad, so I can't comment as to why that is. Also, it's been a few years now since I did C/C++. So, maybe these are no longer the case. Anyway, I've kinda pointed out what I like about clang over gcc, but I'd be curious what you prefer in gcc.
    - hi_herbert 4y ago
      I wonder how up to date is the old belief of better error messages. The was some great redhat blogs about structured error messages in newer GCC.
      - spoiler 4y ago
        Ok, that's kinda true I suppose; I remember that GCC's error messages have indeed gotten better after a major version release. Also, when you say structured, do you mean errors over LSP, or do you mean more structure in the formatting when reporting in CLI?
chrisseaton 4y ago
When a new C++ feature is proposed does the proposer have to provide a reference implementation? How can features be missing from the major compilers?
- pjmlp 4y ago
  Yes to some extent, depends on how one wants to defend their paper at ISO, during the several voting sessions. Even when they do, it is in prototype done by the paper's author, not necessarily something that you can merge right away into upstream. Visual C++ is already there in C++20 and increasingly improving C++23 support as well.
  - chrisseaton 4y ago
    I wonder if a feature has been accepted that turned out to not be tractably implementable! I work on Ruby compilers and people often suggest features that they don’t realise would be catastrophic for performance if implemented, or are sometimes literally impossible to implement.
    - pjmlp 4y ago
      Except Visual C++ already has those ideas implemented, so.... Even exported templates, as hard as they were, the EDG folks actually implemented them, only others decided not to follow upon. The current state with clang is a mix of MIT like license, and those that profit from it not caring about upstream, even GCC is doing better.
      - hi_herbert 4y ago
        I'm pretty sure this rethoric is fallacious, most VMs/languages are not GPL and have MIT-like licenses and yet do not have the issue. It's just that clang lack human resources. Compagnies are not really secretly maintaining their own fork of clang with full support for modern c++. It's not in their economic interest to have to fo all tjis engineering. Instead of malice it'd just plain mediocrity. Yes there are trillion dollars companies that would benefit from better c++ but either they use GCC, either they fail to understand that clang needs funding by pure and quite universal mediocrity. Also the thing is, most languages do not afford to have multiple serious implementations because it is economically absurd, it divide progress by 2 and duplicate the bug surface by 2. GCC at least for the foreseeable future is the de facto C++ implementation.
raverbashing 4y ago
So, it seems most problems are C++ making things extra bureaucratic and annoying. Cool The "pre/post increment of volatiles is deprecated" sounds like a huge pain. I can't imagine a worse waste of developer time than fixing such a minor thing (and to be fair C allowing both a++ / ++a should never have existed)
- mgaunard 4y ago
  well to begin with if you're using volatile, you're probbaly doing something wrong already. The valid use cases for it are ridiculously few.
  - munch117 4y ago
    But if you're using volatile correctly, then there's nothing wrong with ++*v. I was wondering about that slide that says the meaning is unclear, I don't see what's unclear about it. What particular assembly instructions it translates into is irrelevant. It's not like ++ is guaranteed atomic or anything.
    - RicardoLuis0 4y ago
      it's not guaranteed atomic, and if you ARE using volatiles, "maybe" doesn't really cut it, so now you need to do `++*v` the proper way (ex. `lock cmpxchg` / `__atomic_compare_exchange`), or explicitly write it out the long way (`*v = *v + 1`) and risk the small chance of the value changing under you between read/write
    - mgaunard 4y ago
      using volatile correctly usually means you're manipulating write-combining memory. Write-combining memory has weak memory ordering where all writes are delayed so anything doing both reads and writes is most likely going to bite you in the neck.
      - munch117 4y ago
        If you're accessing any kind of I/O register or special memory, obviously you need to know the rules of engagement for the particular kind. If you don't, then you're just going to be making the same mistake in a less obvious guise. Like writing *v=*v+1 instead of *v++.
misnome 4y ago
Wait, so the words "concepts" and "requires" were newly made keywords, and this breaks code, but the words "yield" and "await" were determined too important and too common to standards members that they needed to be renamed to the horrifically ugly "co_await" and "co_yield"? Also, last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now?
- deleted 4y ago
  [deleted]
- StephanTLavavej 4y ago
  std::format is available, with all C++20 Defect Reports implemented, in VS 2019 16.11.14 (and all later 16.11.x) and VS 2022 17.2 (and all later 17.x).
- AlexeyBrin 4y ago
  > last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now? MSVC is the only major implementation that has std::format for now.
  - Forricide 4y ago
    It's so funny to me that MSVC has become the cutting edge of C++ standards implementation. I remember starting out when it was a joke compared to Clang - although I was a novice, so who knows how complete my knowledge was at the time. In any case, it's a really impressive effort from STL and the rest of their library team. STL has some incredible CPPCon talks, too.
    - tialaramex 4y ago
      One way you could interpret this (definitely not the only way) would be that Microsoft - or some group within Microsoft - sees C++ as a possible legacy system, with an opportunity to make a lot of money by judging correctly what customers want and how much income you need to justify that support as existing offerings rust out (so to speak). Do you have any particular CPPCon talks to recommend ? My favourite is "Abseil's Open Source Hashtables: 2 Years In" by Matt Kulukundis, Matt's a fine speaker but what makes it so fun is that Hyrum Wright is in the audience yelling interjections as a result of Hyrum's law (this is scripted). For example Matt explains a significant size optimisation for people who only have a few things in their map, it's just smaller with no other consequences - right? Hyrum points out that now rehash happens earlier, so if you depend on it not to invalidate references during the first 15 insertions you are screwed. Guess whether any real Google code did that...
codeflo 4y ago
Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a sublanguage. I know organizations where migrating to C++11 is still an ongoing process. It’s not great news if features become obsolete faster than many users can adopt them.
- kristopolous 4y ago
  It's a branding problem. They should probably be viewed as different flavors. Using say herbs or colors instead of numbers would help. If every time they're going to add things, remove things and break things then we're in practice talking different strands. Imagine some preprocessor where you can mix them like #flavor(ginger) Instead of say c++11 and then proceed with whatever flavor as necessary. I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation.
  - arinlen 4y ago
    > It's a branding problem. They should probably be viewed as different flavors. They are already different language versions. They're specified in entirely different standards. I don't see what's left to be confused about. At most, perhaps the C++ standard committee could be criticized for repeatedly going out of their way to maximize backward compatibility. > If every time they're going to add things, remove things and break things then we're in practice talking different strands. They are already different standard. What's there to miss? > I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation. This take doesn't make sense. The C++ version being used in a project is a property of the project, not of the translation unit or individual files. A project is comprised of multiple declarations and corresponding definitions, which are spread around and reused and make sense as a whole. It would not make sense to, say, have a translation unit comprised of X C++11 definitions mixed with Y C++20 definitions.
mnahkies 4y ago
My introduction to c++ was a variant of this book https://www.amazon.co.uk/Sams-Teach-Yourself-21-Days/dp/067232072X https://www.amazon.co.uk/Sams-Teach-Yourself-21-Days/dp/0672... when I was about 12. However one thing that really stuck with me was a professor at university saying "if you think you know c++ that just means you don't know it well enough to know you don't know it"
- karolsputo 4y ago
  Your comment reminded me of a beautiful post by Peter Norvig [0]. He covers learning programming and books like the one you mentioned. [0] https://norvig.com/21-days.html https://norvig.com/21-days.html
- soheil 4y ago
  The original quote is from Feynman about quantum mechanics.
- epinephrinios 4y ago
  https://reasonandmeaning.com/2019/11/03/socrates-i-know-that-i-know-nothing/ https://reasonandmeaning.com/2019/11/03/socrates-i-know-that...
imajoredinecon 4y ago
@dang: Would it be better to have the first part of the title be "Google Chrome" or maybe "Chromium"? The content doesn't deal with Google's internal codebase.
- iamstupidsimple 4y ago
  @dang doesn't work, you're best off emailing hn@ycombinator.com
intelVISA 4y ago
Expected the worst but pretty happy with Kasting's breakdown here. Admittedly most of these issues are self-inflicted but at least it's better than the usual "C++ bad" meme
JonChesterfield 4y ago
Way too many of those points are "this sane looking code no longer works, fix by rewriting it to be significantly longer"
- spoiler 4y ago
  I kinda feel bad for taking this jab at C++, since it feels a bit below the belt... But that's kinda C++'s thing, isn't it? You can either do the correct thing, or the succinct thing. There's hardly ever a satisfying compromise between the two either. Obviously, we want to do the correct thing most of the time, so that's why C++ ends up being full of ceremonious implementations in practice. And alas, they're usually equally ceremonious to use, because abstractions in C++ are so incredibly leaky because of its poor type system. I'm not sure why that is, but my gut tells me it's all this backwards [pseudo]compatibility.
  - JonChesterfield 4y ago
    That seems a fair observation to me, with the tweak that "correct" changes over time. C++ code can be written perfectly and still rot as the ecosystem changes, without changing the source. We are really keen on preserving backwards compatibility, but break existing code anyway. We will not define a stable ABI, but also won't fix stdlib if it breaks ABI. Also all code definitely has UB in it waiting for a compiler change to expose it as wrong and deserving of no longer working. Ceremonious captures the state of the art accurately.
    - deadbeeves 4y ago
      >C++ code can be written perfectly and still rot as the ecosystem changes, without changing the source. But that's true of any system that depends on other systems with lax respect for contracts, or with no contract. You can depend on a third-party function get_time() that returns the seconds since the program started, and later on if its maintainers decide to change it to return a UNIX timestamp because they realized the wording was vague enough to allow it, any code that makes the wrong assumption will break. C++ is, I would say, quite good as far as backwards compatibility goes. The problem IMO is that it's rather complex and some of its features have been misunderstood over time, such as the meaning of volatile or inline, and thus people have been writing subtly broken code that just happened to work when they originally wrote it.
leni536 4y ago
Not mentioned here, but some stuff we bumped into: * std::filesystem::path broke some APIs with the introduction of u8string. * some deprecated interfaces of std::allocator got removed. It was easy enough to resolve and we are in the process of switching to C++20.
GnarfGnarf 4y ago
The Boeing 377 Stratocruiser was the epitome of piston technology: 28-cylinder radial engine that needed more maintenance than flying time. It vibrated so hard that it separated from the wing. https://en.wikipedia.org/wiki/Boeing_377_Stratocruiser https://en.wikipedia.org/wiki/Boeing_377_Stratocruiser
- pinkorchid 4y ago
  Maybe you're being hyperbolic, but the catastrophic engine separations in the Stratocruiser were due to propeller failures. http://enginehistory.org/Propellers/B377Props.pdf http://enginehistory.org/Propellers/B377Props.pdf
- B1FF_PSUVM 4y ago
  Leads to https://en.wikipedia.org/wiki/Aero_Spacelines_Pregnant_Guppy https://en.wikipedia.org/wiki/Aero_Spacelines_Pregnant_Guppy As some comedian used to quip, Pregnant Guppy would be a good band name.
germandiago 4y ago
I cannot reply to your comment from "proof?" for gcc is better than clang at generating binaries. But here I found some benchmarks (did not inspect though): https://www.phoronix.com/review/11900k-gcc11-clang12/2 https://www.phoronix.com/review/11900k-gcc11-clang12/2
cletus 4y ago
Just a note but I'm fairly certain this is purely from the perspective of Google Chrome, meaning it excludes google3 (Google's repo for nearly all Google services). I don't know this for a fact but I suspect it's the case. I only bring it up because google3 C++ is (or was; it's now been years since I've done this directly) a very different beast. It was notionally compliant with recent standards but a very restrictive subset of features were allowed. The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. The semantics around moving and copying and the many ways you can initialize a variable [1] and how you can mess that up so it's actually a copy instead of a move is just mind-bending. Can we also talk about how in 2022 we're still talking about and getting wrong const-correctness? I guess we're going ever further now because this presentation touches on constexpr correctness (as in const vs constexpr). Another thought: problems like comparisons between base and derived problems shouldn't even be problems (IMHO) because you've already messed up by wanting that behaviour. The change about not doing arithmetic on enum values is a good one but pretty late. TIL this is a valid way to cast: size_t{expanded_size} [1]: https://en.cppreference.com/w/cpp/language/initialization https://en.cppreference.com/w/cpp/language/initialization
- pjmlp 4y ago
  The standard includes the standard library, a tiny set of pages when compared against Python, Java, F#, C# language reference, VM reference + standard library printout.
- arinlen 4y ago
  > The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. I feel you're embelishing too much your personal feeling of horror. The C++20 standard doc is a hair smaller than 1900 pages, but the complete core language is specified in the first 460 pages, of which around 100 are dedicated to templates. Thus around 1400 pages of a 1900page doc are dedicated to specify libraries that throughout the years have been adopted by the standard. We're talking about stuff that was released with Boost and since then was deemed appropriate to make it standard. Focusing on the 460 pages that specify the core language, most of this content has not been changed since C++98. The C++14 doc covered the core language with around 420 pages. Thus it makes zero sense to claim than suddenly C++ became horrifying because of the extra 20 sheets of paper you need to print out.
philliphaydon 4y ago
This might be a stupid question. But is there performance degradation between versions of c++? I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11. But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.
- d110af5ccf 4y ago
  Those are just versions of the standard. What people would be comparing is the performance of particular implementations. It's entirely possible that a less mature implementation would have problems.
  - philliphaydon 4y ago
    Yeah that makes sense, thanks.
- kadoban 4y ago
  If you're writing the same code, almost certainly not. The only way there would be would be if the compiler either can't optimize something as well because the lang changes requirements (this seems unlikely), or if they have bugs or inefficiencies because they haven't spent much time on the new standard. If you're using new stuff from the new standard, they could be slower or faster or undecidable, really depends.
- jcelerier 4y ago
  There is at least one language-enforced performance improvement: C++17 enforces some amount of RVO. Thus some stuff that would have been copied in previous standard is now not anymore. More standard types supporting move semantics & such also mean that generic code which correctly calls std::move / std::forward may do fewer copies the more recent standard you use.
- pclmulqdq 4y ago
  The "idiomatic" version is slowly getting slower because the idioms are getting higher-level and more expressive. If you don't use the idioms, you can have the same speed. Smart pointers (including unique_ptr<Foo>) have non-zero overhead compared to Foo*. The object oriented parts can introduce significant slowdowns. Template code can have huge code footprints if you are not careful, which slows things down. If you are looking for cycle-level performance, you likely need to use a more C-like subset of the language, but you can still use many conveniences like RAII and the smart pointers with 0 overhead (when construct/destruct are not in the critical path).
tomohawk 4y ago
I mentioned to a former team mate who has been doing c++ for 30 years or so that he might take a look at go or rust for a lot of the things they're doing. His response was, "I already have a new language to learn: c++".
superkuh 4y ago
The word for this is "future shock".
bugfix-66 4y ago
- pclmulqdq 4y ago
  Sometimes you need to avoid GC or have direct control of your threading model and you need a language that is more expressive than C. Your only two options here with broad adoption are C++ and Rust, both of which are very complicated languages. Other languages like Zig, Ocaml, and Erlang have legitimate claims to similar performance to C++/Rust with expressiveness, but they do not have the same adoption.
  - bugfix-66 4y ago
    See my comment elsewhere in this thread, where I argue that Go is a good replacement for C/C++ for almost all purposes.
    - pclmulqdq 4y ago
      I have spent several years writing C++ in circumstances where Go is a terrible C++ replacement. In these cases, you either need manual control of memory or you have extremely tight requirements on either speed or memory usage. In both cases, Go falls short, and C++ actually works relatively well (so does Rust - everything I am saying about C++ here applies to Rust as well). Despite C++ having a large spec and being complicated, it pushes all of that complexity to compile time. At runtime, you pay nothing for the complexity of the language. Please elaborate to me as to why Go is an appropriate C++ replacement for: * Trading systems that use direct NIC access and need sub-microsecond execution times. * Performance-oriented databases (like ScyllaDB or Aerospike). Like trading systems, these are characterized by having custom shared-nothing (often stackless) asynchronous runtimes that need direct control of syscalls, and optimized IPC and synchronization primitives. * Libraries like memcpy, math libraries, compression libraries, and encryption libraries, which need both SIMD intrinsics and minimal overhead compared to assembly implementations (Go fails on the second part of this criterion - even the Go calling convention has significant overhead). And no, you do not need to write these in assembly: C and C++ versions are far more readable and equally fast. * Memory allocators, which cannot circularly depend on another memory allocator. * Embedded systems with constrained memory footprints. * Hardware drivers. * Code for non-CPU machines, like GPUs or DSPs. Almost all the real use cases for Rust, C, or C++ are not suitable for Go. Go is only a suitable replacement for systems programming languages in places where Java is also a suitable replacement: when you have a powerful computer and fairly loose constraints, and you are primarily doing business logic.
synergy20 4y ago
Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. it falls to the saying "a language is either blamed, or nobody uses it". Javascript for the web, Python for machine learning, C for low level and system coding, Go for some native cloud and DevOps, Java for enterprise or Android, C# if you're a windows developer, Swift if you are doing Apple, we actually don't have a lot of choices when you need deliver things faster. I played with nim, ziglang and Rust, but it's hard to use them for real product developments at this point for me.
- bugfix-66 4y ago
  Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway. The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).
  - synergy20 4y ago
    Go will give me VSS of hundred of Gigabits on a MIPS board that has only 64MB memory, it's a known 'feature' by design. Its binary size is at least 10x larger than C/C++. Go also has the stop-the-world GC problem, GC is great but it does have a price tag. I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.
    - bugfix-66 4y ago
      Sure, you can always find extremely constrained, embedded, or real-time safety-critical applications where only a carefully chosen subset of C is applicable. You shouldn't be using the sprawling C++20 there, either. But for pretty much everything else (see the caveats in my comment above) you are better off, a lot better off, using Go.
xyzzy4747 4y ago
I wonder how long it would take an experienced developer to rewrite all of Chrome in Rust. It would probably take a special person though who is an expert in C++, Rust, and the codebase.
- superdimwit 4y ago
  30 years?
  - xyzzy4747 4y ago
    Why do you think that? How complicated could it possibly be? Also as a person becomes more of an expert in a specific thing, they make progress much faster (if they remain motivated). Also it’s just rewriting the logic. One could theoretically write unit tests for every function to make sure the inputs/outputs match.
- epinephrinios 4y ago
  There are no "special" persons or superheroes. It is all about time + money. If a tech giant wants this to happen - e.g. because memory un-safety is mostly the root of all evil - they can use people from the current team and throw a few millions on hiring new talent.
- pkasting 4y ago
  Well, Chrome has many, many hundreds of developers who have worked for many years on the codebase. If we froze the world and turned the whole team over to writing Rust, and we assumed people were perfectly productive in Rust from day one, we could maybe do it in five years.
cpact 4y ago
[dead]
deleted 4y ago
[deleted]
mort96 4y ago
Is there a link to a recording anywhere? I find that slides usually miss a lot of the interesting information. Talks are more than their slides.
- pkasting 4y ago
  Not publicly, unfortunately. This talk was given internally a couple of times.
kwant_kiddo 4y ago
I started reading the link "bans everything to start with anyway" in the slides: https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++-features.md#modern-c_use-in-chromium https://chromium.googlesource.com/chromium/src/+/HEAD/styleg... And I noticed the ban of shared_ptr and <chrono>. I know the use of shard_ptr should be done cautiously, but just banning it from use? How do the Chromium devs solve a problem that requires shared ownership? I guess you can come a long way with singletons and consumer/producer queues. But are raw-pointers just used instead of shared_ptr when shared ownership is needed? Also banning use of <chrono> ? Can someone try to explain the possible reasons?
- adzm 4y ago
  Chromium has an existing ecosystem with a variety of smart pointers already.
  - kwant_kiddo 4y ago
    yeah I found this when stumping upon https://source.chromium.org/chromium https://source.chromium.org/chromium I guess that makes sense as well.
- bialpio 4y ago
  As for <chrono>, the link you provided also has a (short) justification behind the decision: https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++-features.md#date-and-time-utilities-banned https://chromium.googlesource.com/chromium/src/+/HEAD/styleg... Regarding smart pointers, not sure if you also found this: https://chromium.googlesource.com/chromium/src/+/HEAD/base/memory/README.md https://chromium.googlesource.com/chromium/src/+/HEAD/base/m...
- GoblinSlayer 4y ago
  Did you see that <chrono>? C++ committee smoked something unspecified when they ratified <chrono>, but banning it is perfectly reasonable.
schemescape 4y ago
Wow, I didn’t know Google banned exceptions in their C++ code, but the style guide that is linked indicates that they are indeed banned: https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions
- NBJack 4y ago
  Why does this sound familiar? https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions
  - camdenlock 4y ago
    Go = GOAT
- DannyBee 4y ago
  Yes, they have been banned forever, and not just for size reasons. In the end, it makes code very difficult to reason about. It was a deliberate design goal of C++ exceptions that intermediate libraries/callers/etc do not have to be aware of, or handle, exceptions. There is no way to verify or check that all exceptions are caught by someone, etc. This is, as i said, deliberate. This is quite nice in smaller systems, where you pretty much know every dependency and what calls will do. But in larger, complex systems, where it is very hard to know or control every level of dependency, it is quite painful and fragile, because something 37 levels deep might suddenly throw new exceptions (or exceptions at all), violate 0 of the API guarantees that are being made[1], and start crashing your program in edge cases. Among other things [1] It's very easy for one library to say "we throw exceptions, something must catch them", and the dependent to say "we propagate all exceptions, we don't catch them". Even if something promises to catch them in the middle, it will very quickly get lost as it gets further away from the library actually throwing the exceptions. The fact that you may be able to successfully assign blame or root cause to the problem doesn't help - being able to say something like "this library 36 levels deep in my dependency tree is not following best practices" is not a particularly helpful thing for development.
  - 4y ago
worker767424 4y ago
In a few months, I might be switching to a team with a C++ project. A lot of the team is new to C++, and there's nothing about the project that needs C++, Java would have been fine. This doesn't look very fun.
- echelon 4y ago
  If there's ever a big production outage, you can make the case for Java.
  - jupp0r 4y ago
    Because Java is known to magically never cause production outages?
    - echelon 4y ago
      Because the OP described inheriting a C++ app his team doesn't know how to manage. It's a language where segfaults, memory leaks, and other problematic issues are easy to manifest. I assume they have deep Java knowledge, since they suggested it themselves.
      - compiler-guy 4y ago
        This would likely result in worse problems. Things You Should Never Do, Part I https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
        echelon 4y ago
        This has never been my experience, and Joel isn't an all-seeing oracle. In just one notable example, a company I was at had a team develop an important platform in Node.js when the rest of the company was hired for and familiar with Java/Ruby. This app ran our 3rd party API gateway and was a central part of how our company was attempting to grow. The Node.js team left wholesale to go found CockroachDB, which left nobody at the company who had the expertise to take over. You'd think that someone at a fairly large company would have Node.js experience, but it wasn't the case that we could staff the team back up easily. There were several major production outages and the app lagged behind in development for the entirety of its life. We also had to port our protoc changes and traffic stack just to serve this one app. This despite being a central part of our upmarket strategy. Ultimately it was completely rewritten. And nobody regretted that decision. We carefully weighed the pros and cons. There's something to be said for a company that standardizes on one or two languages. Letting engineers have free reign leaves you with Haskell and Erlang littered in important places, with a very tiny bus factor.
kazinator 4y ago
Why only an unhip, old geezer would write outdated drivel like: const int MAX_SIZE = 1024; const int HEADER_SIZE = 128; set_content_size(HEADER_SIZE - MAX_SIZE);
- ncmncm 4y ago
  Probably less geezery to write set_content_size(MAX_SIZE-HEADER_SIZE); Sayin'.
  - kazinator 4y ago
    Never mind the operand order; what do we gain by using constexpr instead of const? In C++, const int x = 3 is already a constant. As of C++98 already, you can use x as a case label in a switch statement. It cannot be any more constant. Not cool any more?
    - ncmncm 4y ago
      You just want to ensure they don't take up space in your struct body. Otherwise, const is fine.
togaen 4y ago
These slides are profoundly uninteresting.
f1shy 4y ago
Honest question, do not want to insult anybody: I've heard lots of times, that the reason why C++ sometimes is weird and complex, is because utter care is taking in maintaining backward compatibility. Sorry if I'm wrong, but I remember seeing a video about variable initialization, which showed many ways of initializing variables, and at the end, the excuse was "all because we have to maintain compatibility to C". No my question, again, please do not think I'm insulting anybody: This presentation seems to show the compatibility between most recent releases is not very good. What am I missing here?
- mrazomor 4y ago
  The presentation mostly lists warnings and notices about deprecation. If you turn them all off, most likely the compilation would pass. So, backwards compatibility is there (if we ignore newly introduced keywords).
- MauranKilom 4y ago
  > This presentation seems to show the compatibility between most recent releases is not very good. Half of the "features" shown in the presentation are exceedingly niche. It's just that a 20 million LOC (or however many Chrome has right now) code base is almost guaranteed to exercise every niche feature somewhere. Having helped with C++ standard transitions of a code base half an order of magnitude smaller, the amount of issues requiring code changes was minuscule so far. You tend to have much more boring problems, like: - "We can't use newer C++ because C++/CLI doesn't support it" - "We can't use newer C++ in these headers because they end up included in CUDA code, and that compiler only supports C++14" - "We have to wait for a new version of <tool> before we can lint/sanitize/profile/format our code" - "This third-party code has the compiler up in arms now because it does questionable things"
  - pjmlp 4y ago
    Yep, C++/CLI is stuck on C++17, and apparently will stay like that.
sbf501 4y ago
Slide 37: can't even use ++ anymore. Ouch. (at least on volatile, but still) Best line in the deck: "Only write complicated code when you truly need performance. Comment if you do...."
camdenlock 4y ago
I’m usually somewhat critical of Rust… but not when I encounter C++. What an over-engineered shitshow. Rust looks like a simple set of useful tools compared to C++’s convoluted warehouse of horrors.
- ncmncm 4y ago
  What you don't use, you don't understand.
WalterBright 4y ago
I had a great time implementing a C compiler and embedding it in the D compiler so it can import C code directly. I keep toying with the idea of doing that for C++, but since C++98 the language has just gotten too complicated to reliably map onto D semantics.
- humanrebar 4y ago
  I have been thinking of this D non-feature when reading up on the Carbon approach. Do you have any takes on how Carbon could be successful on mapping to C++ when D considers it too much of a reach?
  - WalterBright 4y ago
    I don't know anything about Carbon. But a reasonable approach would be to use an existing C++ compiler and intercept its ASTs.
- Decabytes 4y ago
  with import C what is the benefit of creating bindings to C libraries if you can just work with the C code directly?
  - WalterBright 4y ago
    ImportC can handle the .h files and/or the .c files, as the user prefers.
  - schveiguy 4y ago
    import C is not perfect. There are pieces of C that don't map directly to D. Such as #define constants and macros. That being said, it will make writing bindings a LOT easier, even though D already has direct binding to C functions.
r2vcap 4y ago
C++20 is hard, but Peter Kasting's presentation is really easy to understand. I learned a lot. Also, I don't understand why there are so many negative views on C++. C++ is a beast, but somehow you can control it, and C++ is too popular and still in use to be replaced by anything else in the near future.
account42 4y ago
> Problem: Early test showed release binary size increased by 0.9% (Win) I guess once again you do actually end up paying for what you don't use. > Solution: Don’t care? :( Would have been nice if they at least analyzed where the increase was coming from. Maybe operator<=>?

330 points by pyler 4y ago

oxff 4y ago

Writing Chromium grade C++ seems like a hard job with all these extrinsic rules and regulations to make it work

meibo 4y ago
You'll see these kind of rules at every place that cares about their C++ codebase. It's just not a language like Java, C# or JS where you can throw stuff at the wall and it'll probably work out.
- otabdeveloper4 4y ago
  > Java, C# Maybe. > JS Hell no. "Frameworks" like React or Vue exist solely for the purpose of retaining developer sanity in the face of unregulated JS code.
- speedgoose 4y ago
  Anyone serious with TypeScript/JavaScript has many Eslint rules to keep the codebase sain.
  - white_dragon88 4y ago
    [dead]
- pjmlp 4y ago
  Even for Java, C# and JS we do enforce such kind of rules, e.g. https://sonarqube.org https://sonarqube.org

amelius 4y ago

I stopped using C++ after lambdas were introduced (10 years ago or so?) Is there anything I can read to get up to date quickly?

smhaziq 4y ago
https://learn.microsoft.com/en-us/cpp/cpp/welcome-back-to-cpp-modern-cpp?view=msvc-170 https://learn.microsoft.com/en-us/cpp/cpp/welcome-back-to-cp...
stefanos82 4y ago
I would suggest to go through https://github.com/AnthonyCalandra/modern-cpp-features https://github.com/AnthonyCalandra/modern-cpp-features ; it's quite clean.
- kristopolous 4y ago
  Broken link
  - pivo 4y ago
    Remove the trailing semicolon https://github.com/AnthonyCalandra/modern-cpp-features https://github.com/AnthonyCalandra/modern-cpp-features
pjmlp 4y ago
Bjarne's "Tour of C++", 3rd edition.

diceduckmonk 4y ago

Is there a case for or against incrementally adopting Rust ?

glandium 4y ago
They are experimenting https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rust-toolchain.md https://chromium.googlesource.com/chromium/src/+/refs/heads/...
- Existenceblinks 4y ago
  Is there any common module that can be shared amongst browser engines? I can feel though it sounds hard to extract these common stuff into .. "browser engine common core"? (e.g. https://github.com/SerenityOS/serenity/tree/master/Userland/Libraries/LibWeb https://github.com/SerenityOS/serenity/tree/master/Userland/...). That would be nice for next gen browser invention.
  - sbdncuvh 4y ago
  - hi_herbert 4y ago
    You can find some module candidates here https://github.com/servo/servo/issues/24026#issue-483508434 https://github.com/servo/servo/issues/24026#issue-483508434 The one that make the most economic sense would be for mozilla to drop spidermonkey and make v8 faster instead
izacus 4y ago
Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?
- otabdeveloper4 4y ago
  Don't worry your little brain about these silly things. Programming is hard, let's go (language) shopping instead!

pornel 4y ago

Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.

forgotpwd16 4y ago
It doesn't cause problems as in old things don't work as in it takes time to get advantage of newly introduced ones and replace anything considered deprecated (edit: and rename variables clashing with new keywords).
TonyTrapp 4y ago
From what I can gather, a majority of the problems reported there are new compiler warnings being triggered. Especially if you enable all compiler warnings to catch potential defects, any upgrade to a new compiler version will typically introduce a ton of new warnings that you have to work around. Edit: There are also quite a few deprecation warnings, which are also not errors per se, but nevertheless you'd want to avoid using deprecated stuff of course.
IshKebab 4y ago
It generally does although they have made technically breaking changes in the past (e.g. `auto`). This is the first release I've used where they broke something in actual code I use because of the comparison operator changes. However it was easy to fix and actually it was because whoever wrote it did it wrong. Google also found a breakage that was hiding a bug. So maybe their new stance is "only break incorrect code"? I dunno. I feel like a small amount of breakage is reasonable anyway. Breaking change absolutionists are generally just being dogmatic, and haven't really thought through what zero breaking changes really implies. E.g. in languages with introspection it technically means you can't change anything.
- pjmlp 4y ago
  They also broke the code of the few users that made use of exception specifications.
pjmlp 4y ago

dureuill 4y ago

As expected modules are relegated to some later time ("will be its own experiment")

pjmlp 4y ago
Thanks clang lagging behind ISO C++, you can use them today on Visual Studio 2022.
- mike_hock 4y ago
  Can't blame them. Modules are Microsoft sabotaging the standard so they can be the only conforming implementation, just like with the Office .doc format. Modules are unimplementable shite. They would be great if this was the first iteration of the language, but they're a nightmare to fit into the existing ecosystem. If they get support in open source compilers, we can look forward to at least one or two decades of a mixed modules/headers mess in open source projects.
  - pjmlp 4y ago
    Yet, somehow the GCC folks manage to keep improving their modules support, slow and steady. If they were unimplementable, there wouldn't exist already two major C++ compilers supporting them to some degree. It is only clang with their module maps pseudo concept that keeps lagging, that and plenty of other C++20 features.
    - mike_hock 4y ago
      Implementable by compilers, sure. Implementable by the ecosystem at large, yes, over the course of several decades. Edit: Also, module support better be 100% binary compatible between GCC and Clang, or it's worse than complete garbage.
      - pjmlp 4y ago
        As if you could expect any kind of ABI compatibility between GCC and clang binary libraries today, and apparently it doesn't make them a complete garbage, go figure.

khoobid_shoma 4y ago

It's easier to say goodbye C++!

speedgoose 4y ago
A full rewrite seems extremely expensive and long. I’m afraid C++ isn’t going anywhere in our lifetime.
- Kwpolska 4y ago
  C++ can stay, but people can make a decision not to use it for anything and not to take any jobs involving C++ (or other systems/bare-metal-ish languages).
pjmlp 4y ago
C is 10 years younger than COBOL, C++ is 20 years younger than COBOL, COBOL is still around.
krater23 4y ago
It's more easy to just don't adopt the new standard.
butterisgood 4y ago
I've written a fair amount of C++ in my day, and this seems totally unacceptable to me. Also my opinion seems unpopular on this topic, so I suspect some group of people that really want to get behind C++ don't like that kind of talk. Whatever though. Rust and other newer languages are kind of giving the spaces C++ works well in a run for its money and in other ways just completely blowing it out of the water in my opinion. It might be time to look at D again too.

butterisgood 4y ago

Damn. May as well have used a language that isn’t released yet like Zig. That’s a ton of problems.

TinkersW 4y ago
Um no. When I upgraded it was a few hours of work at most, for Google since its code base is extremely large maybe a few days to weeks.
- Matumio 4y ago
  Probably no big issue for a small to medium codebase. But I doubt the "just a few days" estimate for something as big as a web-browser. If I read correctly they even found use-after-move bugs during the process.
  - TinkersW 4y ago
    The use after move existed prior, just wasn't moving even though they had written move. It is also written in a way that a linter should be able to detect if you disallow use after move. https://source.chromium.org/chromium/chromium/src/+/main:components/services/storage/indexed_db/locks/disjoint_range_lock_manager.cc;l=136;drc=2705e1173e88110a9778b88a1c3e1be8d103f7e9 https://source.chromium.org/chromium/chromium/src/+/main:com...
    - pkasting 4y ago
      It's surprisingly hard to detect these sorts of cases reliably; we have a request out to the clang-tidy folks to add some improved detection of use-after-move there.
- pkasting 4y ago
  Took a couple of months actually, but it's mostly complete now and we're starting to throw the switches.
ninepoints 4y ago

mrazomor 4y ago

Very useful presentation. Full of details, but easy to consume. On voices against stripped down C++ (via code style): I find it working great in practice. Makes the codebase manageable, and keeps people away from using unnecessary complex language features (imagine Java code heavy with streams or reflection, or Python code that resolves most of dependencies at runtime, javascript full of eval(), etc.). Switching to a new language is half-baked plan.

hi_herbert 4y ago
Ad-hoc black or white bans are very retrograde and costly for tje most part and usually stem from purity thinking. Case in point reflection in Java is a godsend. I use it very rarely because it'd uses only comes for very specific needs but when I use it, the alternative either doed not exist or usually would be much more uglier. As for streams well it's just regular functors (map, filter) they are used in every language and are very useful. Now I agree about two things: 1) the stream api is a bit (not that much though) verbose, which significantly contrast with Kotlin. Although e.g .toList() helps 2) yes develpers especially junior ones are eager to abuse functors in an unreadable mess. When there is complexity using loops is usually more readable. Streams however are very fit for regular ETL that represents ~70% of code for most simple apps. The pinnacle of complexity would be e.g. Reactive streams such as rxjava. I agree python dependencies are a worldwide shame and eval() is very niche (but again should not be universality banned assuming good developers, maybe though one could conditionally ban it aka it would trigger a lint during code review that would need explicit validation. As for the topic at hands, google style bans are insane e.g. No Exceptions lol
- f1shy 4y ago
  I agree with this comment, and cannot understand why is downvoted. I would like the one that downvoted comments on why. My thinking, more or less in line with the comment is: instead of investing energy, time and resources in writing laws of what is allowed and what no (often without rationale). Use that time, effort and energy in educating developers, so that, if those prohibitions are really sensible, they will anyway refrain from doing that. You get the benefit of not having to change the bans. By doing regular code reviews, you can detect ill formed code, and discuss with the developers. Maybe some developer has something to teach to the "big experts" who write those documents?

pjmlp 4y ago

It is so ironic, that now that Apple and Google decided to focus on their own language stacks, the C and C++ compiler vendors that profit from clang's license aren't that keen in making the upstream work for catching up with ISO C++. Thus making the once famous clang having an honorable third place in ISO C++ compliancy. Seeing this from a Google team makes it even more ironic.

otabdeveloper4 4y ago
gcc is better than clang on every metric. Sorry, it's the facts. ¯\_(ツ)_/¯
- spoiler 4y ago
  I've always preferred clang for its better lints, and friendlier error messages (sans some decrepit parts around templates that are equally horrendous everywhere)... And theoretically clang has better ASM output in some cases I say theoretically, because it's been shown that GCC's "worse" ASM performs better; I'm not really an architecture aficionad, so I can't comment as to why that is. Also, it's been a few years now since I did C/C++. So, maybe these are no longer the case. Anyway, I've kinda pointed out what I like about clang over gcc, but I'd be curious what you prefer in gcc.
  - hi_herbert 4y ago
    I wonder how up to date is the old belief of better error messages. The was some great redhat blogs about structured error messages in newer GCC.
    - spoiler 4y ago
      Ok, that's kinda true I suppose; I remember that GCC's error messages have indeed gotten better after a major version release. Also, when you say structured, do you mean errors over LSP, or do you mean more structure in the formatting when reporting in CLI?

chrisseaton 4y ago

When a new C++ feature is proposed does the proposer have to provide a reference implementation? How can features be missing from the major compilers?

pjmlp 4y ago
Yes to some extent, depends on how one wants to defend their paper at ISO, during the several voting sessions. Even when they do, it is in prototype done by the paper's author, not necessarily something that you can merge right away into upstream. Visual C++ is already there in C++20 and increasingly improving C++23 support as well.
- chrisseaton 4y ago
  I wonder if a feature has been accepted that turned out to not be tractably implementable! I work on Ruby compilers and people often suggest features that they don’t realise would be catastrophic for performance if implemented, or are sometimes literally impossible to implement.
  - pjmlp 4y ago
    Except Visual C++ already has those ideas implemented, so.... Even exported templates, as hard as they were, the EDG folks actually implemented them, only others decided not to follow upon. The current state with clang is a mix of MIT like license, and those that profit from it not caring about upstream, even GCC is doing better.
    - hi_herbert 4y ago
      I'm pretty sure this rethoric is fallacious, most VMs/languages are not GPL and have MIT-like licenses and yet do not have the issue. It's just that clang lack human resources. Compagnies are not really secretly maintaining their own fork of clang with full support for modern c++. It's not in their economic interest to have to fo all tjis engineering. Instead of malice it'd just plain mediocrity. Yes there are trillion dollars companies that would benefit from better c++ but either they use GCC, either they fail to understand that clang needs funding by pure and quite universal mediocrity. Also the thing is, most languages do not afford to have multiple serious implementations because it is economically absurd, it divide progress by 2 and duplicate the bug surface by 2. GCC at least for the foreseeable future is the de facto C++ implementation.

raverbashing 4y ago

So, it seems most problems are C++ making things extra bureaucratic and annoying. Cool The "pre/post increment of volatiles is deprecated" sounds like a huge pain. I can't imagine a worse waste of developer time than fixing such a minor thing (and to be fair C allowing both a++ / ++a should never have existed)

mgaunard 4y ago
well to begin with if you're using volatile, you're probbaly doing something wrong already. The valid use cases for it are ridiculously few.
- munch117 4y ago
  But if you're using volatile correctly, then there's nothing wrong with ++*v. I was wondering about that slide that says the meaning is unclear, I don't see what's unclear about it. What particular assembly instructions it translates into is irrelevant. It's not like ++ is guaranteed atomic or anything.
  - RicardoLuis0 4y ago
    it's not guaranteed atomic, and if you ARE using volatiles, "maybe" doesn't really cut it, so now you need to do `++*v` the proper way (ex. `lock cmpxchg` / `__atomic_compare_exchange`), or explicitly write it out the long way (`*v = *v + 1`) and risk the small chance of the value changing under you between read/write
  - mgaunard 4y ago
    using volatile correctly usually means you're manipulating write-combining memory. Write-combining memory has weak memory ordering where all writes are delayed so anything doing both reads and writes is most likely going to bite you in the neck.
    - munch117 4y ago
      If you're accessing any kind of I/O register or special memory, obviously you need to know the rules of engagement for the particular kind. If you don't, then you're just going to be making the same mistake in a less obvious guise. Like writing *v=*v+1 instead of *v++.

misnome 4y ago

Wait, so the words "concepts" and "requires" were newly made keywords, and this breaks code, but the words "yield" and "await" were determined too important and too common to standards members that they needed to be renamed to the horrifically ugly "co_await" and "co_yield"? Also, last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now?

deleted 4y ago
[deleted]
StephanTLavavej 4y ago
std::format is available, with all C++20 Defect Reports implemented, in VS 2019 16.11.14 (and all later 16.11.x) and VS 2022 17.2 (and all later 17.x).
AlexeyBrin 4y ago
> last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now? MSVC is the only major implementation that has std::format for now.
- Forricide 4y ago
  It's so funny to me that MSVC has become the cutting edge of C++ standards implementation. I remember starting out when it was a joke compared to Clang - although I was a novice, so who knows how complete my knowledge was at the time. In any case, it's a really impressive effort from STL and the rest of their library team. STL has some incredible CPPCon talks, too.
  - tialaramex 4y ago
    One way you could interpret this (definitely not the only way) would be that Microsoft - or some group within Microsoft - sees C++ as a possible legacy system, with an opportunity to make a lot of money by judging correctly what customers want and how much income you need to justify that support as existing offerings rust out (so to speak). Do you have any particular CPPCon talks to recommend ? My favourite is "Abseil's Open Source Hashtables: 2 Years In" by Matt Kulukundis, Matt's a fine speaker but what makes it so fun is that Hyrum Wright is in the audience yelling interjections as a result of Hyrum's law (this is scripted). For example Matt explains a significant size optimisation for people who only have a few things in their map, it's just smaller with no other consequences - right? Hyrum points out that now rehash happens earlier, so if you depend on it not to invalidate references during the first 15 insertions you are screwed. Guess whether any real Google code did that...

codeflo 4y ago

Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a sublanguage. I know organizations where migrating to C++11 is still an ongoing process. It’s not great news if features become obsolete faster than many users can adopt them.

kristopolous 4y ago
It's a branding problem. They should probably be viewed as different flavors. Using say herbs or colors instead of numbers would help. If every time they're going to add things, remove things and break things then we're in practice talking different strands. Imagine some preprocessor where you can mix them like #flavor(ginger) Instead of say c++11 and then proceed with whatever flavor as necessary. I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation.
- arinlen 4y ago
  > It's a branding problem. They should probably be viewed as different flavors. They are already different language versions. They're specified in entirely different standards. I don't see what's left to be confused about. At most, perhaps the C++ standard committee could be criticized for repeatedly going out of their way to maximize backward compatibility. > If every time they're going to add things, remove things and break things then we're in practice talking different strands. They are already different standard. What's there to miss? > I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation. This take doesn't make sense. The C++ version being used in a project is a property of the project, not of the translation unit or individual files. A project is comprised of multiple declarations and corresponding definitions, which are spread around and reused and make sense as a whole. It would not make sense to, say, have a translation unit comprised of X C++11 definitions mixed with Y C++20 definitions.

mnahkies 4y ago

My introduction to c++ was a variant of this book https://www.amazon.co.uk/Sams-Teach-Yourself-21-Days/dp/067232072X https://www.amazon.co.uk/Sams-Teach-Yourself-21-Days/dp/0672... when I was about 12. However one thing that really stuck with me was a professor at university saying "if you think you know c++ that just means you don't know it well enough to know you don't know it"

karolsputo 4y ago
Your comment reminded me of a beautiful post by Peter Norvig [0]. He covers learning programming and books like the one you mentioned. [0] https://norvig.com/21-days.html https://norvig.com/21-days.html
soheil 4y ago
The original quote is from Feynman about quantum mechanics.
epinephrinios 4y ago
https://reasonandmeaning.com/2019/11/03/socrates-i-know-that-i-know-nothing/ https://reasonandmeaning.com/2019/11/03/socrates-i-know-that...

imajoredinecon 4y ago

@dang: Would it be better to have the first part of the title be "Google Chrome" or maybe "Chromium"? The content doesn't deal with Google's internal codebase.

iamstupidsimple 4y ago
@dang doesn't work, you're best off emailing hn@ycombinator.com

intelVISA 4y ago

Expected the worst but pretty happy with Kasting's breakdown here. Admittedly most of these issues are self-inflicted but at least it's better than the usual "C++ bad" meme

JonChesterfield 4y ago

Way too many of those points are "this sane looking code no longer works, fix by rewriting it to be significantly longer"

spoiler 4y ago
I kinda feel bad for taking this jab at C++, since it feels a bit below the belt... But that's kinda C++'s thing, isn't it? You can either do the correct thing, or the succinct thing. There's hardly ever a satisfying compromise between the two either. Obviously, we want to do the correct thing most of the time, so that's why C++ ends up being full of ceremonious implementations in practice. And alas, they're usually equally ceremonious to use, because abstractions in C++ are so incredibly leaky because of its poor type system. I'm not sure why that is, but my gut tells me it's all this backwards [pseudo]compatibility.
- JonChesterfield 4y ago
  That seems a fair observation to me, with the tweak that "correct" changes over time. C++ code can be written perfectly and still rot as the ecosystem changes, without changing the source. We are really keen on preserving backwards compatibility, but break existing code anyway. We will not define a stable ABI, but also won't fix stdlib if it breaks ABI. Also all code definitely has UB in it waiting for a compiler change to expose it as wrong and deserving of no longer working. Ceremonious captures the state of the art accurately.
  - deadbeeves 4y ago
    >C++ code can be written perfectly and still rot as the ecosystem changes, without changing the source. But that's true of any system that depends on other systems with lax respect for contracts, or with no contract. You can depend on a third-party function get_time() that returns the seconds since the program started, and later on if its maintainers decide to change it to return a UNIX timestamp because they realized the wording was vague enough to allow it, any code that makes the wrong assumption will break. C++ is, I would say, quite good as far as backwards compatibility goes. The problem IMO is that it's rather complex and some of its features have been misunderstood over time, such as the meaning of volatile or inline, and thus people have been writing subtly broken code that just happened to work when they originally wrote it.

leni536 4y ago

Not mentioned here, but some stuff we bumped into: * std::filesystem::path broke some APIs with the introduction of u8string. * some deprecated interfaces of std::allocator got removed. It was easy enough to resolve and we are in the process of switching to C++20.

GnarfGnarf 4y ago

The Boeing 377 Stratocruiser was the epitome of piston technology: 28-cylinder radial engine that needed more maintenance than flying time. It vibrated so hard that it separated from the wing. https://en.wikipedia.org/wiki/Boeing_377_Stratocruiser https://en.wikipedia.org/wiki/Boeing_377_Stratocruiser

pinkorchid 4y ago
Maybe you're being hyperbolic, but the catastrophic engine separations in the Stratocruiser were due to propeller failures. http://enginehistory.org/Propellers/B377Props.pdf http://enginehistory.org/Propellers/B377Props.pdf
B1FF_PSUVM 4y ago
Leads to https://en.wikipedia.org/wiki/Aero_Spacelines_Pregnant_Guppy https://en.wikipedia.org/wiki/Aero_Spacelines_Pregnant_Guppy As some comedian used to quip, Pregnant Guppy would be a good band name.

germandiago 4y ago

I cannot reply to your comment from "proof?" for gcc is better than clang at generating binaries. But here I found some benchmarks (did not inspect though): https://www.phoronix.com/review/11900k-gcc11-clang12/2 https://www.phoronix.com/review/11900k-gcc11-clang12/2

cletus 4y ago

Just a note but I'm fairly certain this is purely from the perspective of Google Chrome, meaning it excludes google3 (Google's repo for nearly all Google services). I don't know this for a fact but I suspect it's the case. I only bring it up because google3 C++ is (or was; it's now been years since I've done this directly) a very different beast. It was notionally compliant with recent standards but a very restrictive subset of features were allowed. The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. The semantics around moving and copying and the many ways you can initialize a variable [1] and how you can mess that up so it's actually a copy instead of a move is just mind-bending. Can we also talk about how in 2022 we're still talking about and getting wrong const-correctness? I guess we're going ever further now because this presentation touches on constexpr correctness (as in const vs constexpr). Another thought: problems like comparisons between base and derived problems shouldn't even be problems (IMHO) because you've already messed up by wanting that behaviour. The change about not doing arithmetic on enum values is a good one but pretty late. TIL this is a valid way to cast: size_t{expanded_size} [1]: https://en.cppreference.com/w/cpp/language/initialization https://en.cppreference.com/w/cpp/language/initialization

pjmlp 4y ago
The standard includes the standard library, a tiny set of pages when compared against Python, Java, F#, C# language reference, VM reference + standard library printout.
arinlen 4y ago
> The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. I feel you're embelishing too much your personal feeling of horror. The C++20 standard doc is a hair smaller than 1900 pages, but the complete core language is specified in the first 460 pages, of which around 100 are dedicated to templates. Thus around 1400 pages of a 1900page doc are dedicated to specify libraries that throughout the years have been adopted by the standard. We're talking about stuff that was released with Boost and since then was deemed appropriate to make it standard. Focusing on the 460 pages that specify the core language, most of this content has not been changed since C++98. The C++14 doc covered the core language with around 420 pages. Thus it makes zero sense to claim than suddenly C++ became horrifying because of the extra 20 sheets of paper you need to print out.

philliphaydon 4y ago

This might be a stupid question. But is there performance degradation between versions of c++? I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11. But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.

d110af5ccf 4y ago
Those are just versions of the standard. What people would be comparing is the performance of particular implementations. It's entirely possible that a less mature implementation would have problems.
- philliphaydon 4y ago
  Yeah that makes sense, thanks.
kadoban 4y ago
If you're writing the same code, almost certainly not. The only way there would be would be if the compiler either can't optimize something as well because the lang changes requirements (this seems unlikely), or if they have bugs or inefficiencies because they haven't spent much time on the new standard. If you're using new stuff from the new standard, they could be slower or faster or undecidable, really depends.
jcelerier 4y ago
There is at least one language-enforced performance improvement: C++17 enforces some amount of RVO. Thus some stuff that would have been copied in previous standard is now not anymore. More standard types supporting move semantics & such also mean that generic code which correctly calls std::move / std::forward may do fewer copies the more recent standard you use.
pclmulqdq 4y ago
The "idiomatic" version is slowly getting slower because the idioms are getting higher-level and more expressive. If you don't use the idioms, you can have the same speed. Smart pointers (including unique_ptr<Foo>) have non-zero overhead compared to Foo*. The object oriented parts can introduce significant slowdowns. Template code can have huge code footprints if you are not careful, which slows things down. If you are looking for cycle-level performance, you likely need to use a more C-like subset of the language, but you can still use many conveniences like RAII and the smart pointers with 0 overhead (when construct/destruct are not in the critical path).

tomohawk 4y ago

I mentioned to a former team mate who has been doing c++ for 30 years or so that he might take a look at go or rust for a lot of the things they're doing. His response was, "I already have a new language to learn: c++".

superkuh 4y ago

The word for this is "future shock".

bugfix-66 4y ago

pclmulqdq 4y ago
Sometimes you need to avoid GC or have direct control of your threading model and you need a language that is more expressive than C. Your only two options here with broad adoption are C++ and Rust, both of which are very complicated languages. Other languages like Zig, Ocaml, and Erlang have legitimate claims to similar performance to C++/Rust with expressiveness, but they do not have the same adoption.
- bugfix-66 4y ago
  See my comment elsewhere in this thread, where I argue that Go is a good replacement for C/C++ for almost all purposes.
  - pclmulqdq 4y ago
    I have spent several years writing C++ in circumstances where Go is a terrible C++ replacement. In these cases, you either need manual control of memory or you have extremely tight requirements on either speed or memory usage. In both cases, Go falls short, and C++ actually works relatively well (so does Rust - everything I am saying about C++ here applies to Rust as well). Despite C++ having a large spec and being complicated, it pushes all of that complexity to compile time. At runtime, you pay nothing for the complexity of the language. Please elaborate to me as to why Go is an appropriate C++ replacement for: * Trading systems that use direct NIC access and need sub-microsecond execution times. * Performance-oriented databases (like ScyllaDB or Aerospike). Like trading systems, these are characterized by having custom shared-nothing (often stackless) asynchronous runtimes that need direct control of syscalls, and optimized IPC and synchronization primitives. * Libraries like memcpy, math libraries, compression libraries, and encryption libraries, which need both SIMD intrinsics and minimal overhead compared to assembly implementations (Go fails on the second part of this criterion - even the Go calling convention has significant overhead). And no, you do not need to write these in assembly: C and C++ versions are far more readable and equally fast. * Memory allocators, which cannot circularly depend on another memory allocator. * Embedded systems with constrained memory footprints. * Hardware drivers. * Code for non-CPU machines, like GPUs or DSPs. Almost all the real use cases for Rust, C, or C++ are not suitable for Go. Go is only a suitable replacement for systems programming languages in places where Java is also a suitable replacement: when you have a powerful computer and fairly loose constraints, and you are primarily doing business logic.

synergy20 4y ago

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. it falls to the saying "a language is either blamed, or nobody uses it". Javascript for the web, Python for machine learning, C for low level and system coding, Go for some native cloud and DevOps, Java for enterprise or Android, C# if you're a windows developer, Swift if you are doing Apple, we actually don't have a lot of choices when you need deliver things faster. I played with nim, ziglang and Rust, but it's hard to use them for real product developments at this point for me.

bugfix-66 4y ago
Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway. The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).
- synergy20 4y ago
  Go will give me VSS of hundred of Gigabits on a MIPS board that has only 64MB memory, it's a known 'feature' by design. Its binary size is at least 10x larger than C/C++. Go also has the stop-the-world GC problem, GC is great but it does have a price tag. I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.
  - bugfix-66 4y ago
    Sure, you can always find extremely constrained, embedded, or real-time safety-critical applications where only a carefully chosen subset of C is applicable. You shouldn't be using the sprawling C++20 there, either. But for pretty much everything else (see the caveats in my comment above) you are better off, a lot better off, using Go.

xyzzy4747 4y ago

I wonder how long it would take an experienced developer to rewrite all of Chrome in Rust. It would probably take a special person though who is an expert in C++, Rust, and the codebase.

superdimwit 4y ago
30 years?
- xyzzy4747 4y ago
  Why do you think that? How complicated could it possibly be? Also as a person becomes more of an expert in a specific thing, they make progress much faster (if they remain motivated). Also it’s just rewriting the logic. One could theoretically write unit tests for every function to make sure the inputs/outputs match.
epinephrinios 4y ago
There are no "special" persons or superheroes. It is all about time + money. If a tech giant wants this to happen - e.g. because memory un-safety is mostly the root of all evil - they can use people from the current team and throw a few millions on hiring new talent.
pkasting 4y ago
Well, Chrome has many, many hundreds of developers who have worked for many years on the codebase. If we froze the world and turned the whole team over to writing Rust, and we assumed people were perfectly productive in Rust from day one, we could maybe do it in five years.

cpact 4y ago

[dead]

deleted 4y ago

[deleted]

mort96 4y ago

Is there a link to a recording anywhere? I find that slides usually miss a lot of the interesting information. Talks are more than their slides.

pkasting 4y ago
Not publicly, unfortunately. This talk was given internally a couple of times.

kwant_kiddo 4y ago

I started reading the link "bans everything to start with anyway" in the slides: https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++-features.md#modern-c_use-in-chromium https://chromium.googlesource.com/chromium/src/+/HEAD/styleg... And I noticed the ban of shared_ptr and <chrono>. I know the use of shard_ptr should be done cautiously, but just banning it from use? How do the Chromium devs solve a problem that requires shared ownership? I guess you can come a long way with singletons and consumer/producer queues. But are raw-pointers just used instead of shared_ptr when shared ownership is needed? Also banning use of <chrono> ? Can someone try to explain the possible reasons?

adzm 4y ago
Chromium has an existing ecosystem with a variety of smart pointers already.
- kwant_kiddo 4y ago
  yeah I found this when stumping upon https://source.chromium.org/chromium https://source.chromium.org/chromium I guess that makes sense as well.
bialpio 4y ago
As for <chrono>, the link you provided also has a (short) justification behind the decision: https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++-features.md#date-and-time-utilities-banned https://chromium.googlesource.com/chromium/src/+/HEAD/styleg... Regarding smart pointers, not sure if you also found this: https://chromium.googlesource.com/chromium/src/+/HEAD/base/memory/README.md https://chromium.googlesource.com/chromium/src/+/HEAD/base/m...
GoblinSlayer 4y ago
Did you see that <chrono>? C++ committee smoked something unspecified when they ratified <chrono>, but banning it is perfectly reasonable.

schemescape 4y ago

Wow, I didn’t know Google banned exceptions in their C++ code, but the style guide that is linked indicates that they are indeed banned: https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions

NBJack 4y ago
Why does this sound familiar? https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions
- camdenlock 4y ago
  Go = GOAT
DannyBee 4y ago
Yes, they have been banned forever, and not just for size reasons. In the end, it makes code very difficult to reason about. It was a deliberate design goal of C++ exceptions that intermediate libraries/callers/etc do not have to be aware of, or handle, exceptions. There is no way to verify or check that all exceptions are caught by someone, etc. This is, as i said, deliberate. This is quite nice in smaller systems, where you pretty much know every dependency and what calls will do. But in larger, complex systems, where it is very hard to know or control every level of dependency, it is quite painful and fragile, because something 37 levels deep might suddenly throw new exceptions (or exceptions at all), violate 0 of the API guarantees that are being made[1], and start crashing your program in edge cases. Among other things [1] It's very easy for one library to say "we throw exceptions, something must catch them", and the dependent to say "we propagate all exceptions, we don't catch them". Even if something promises to catch them in the middle, it will very quickly get lost as it gets further away from the library actually throwing the exceptions. The fact that you may be able to successfully assign blame or root cause to the problem doesn't help - being able to say something like "this library 36 levels deep in my dependency tree is not following best practices" is not a particularly helpful thing for development.
- 4y ago

worker767424 4y ago

In a few months, I might be switching to a team with a C++ project. A lot of the team is new to C++, and there's nothing about the project that needs C++, Java would have been fine. This doesn't look very fun.

echelon 4y ago
If there's ever a big production outage, you can make the case for Java.
- jupp0r 4y ago
  Because Java is known to magically never cause production outages?
  - echelon 4y ago
    Because the OP described inheriting a C++ app his team doesn't know how to manage. It's a language where segfaults, memory leaks, and other problematic issues are easy to manifest. I assume they have deep Java knowledge, since they suggested it themselves.
    - compiler-guy 4y ago
      This would likely result in worse problems. Things You Should Never Do, Part I https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
      - echelon 4y ago
        This has never been my experience, and Joel isn't an all-seeing oracle. In just one notable example, a company I was at had a team develop an important platform in Node.js when the rest of the company was hired for and familiar with Java/Ruby. This app ran our 3rd party API gateway and was a central part of how our company was attempting to grow. The Node.js team left wholesale to go found CockroachDB, which left nobody at the company who had the expertise to take over. You'd think that someone at a fairly large company would have Node.js experience, but it wasn't the case that we could staff the team back up easily. There were several major production outages and the app lagged behind in development for the entirety of its life. We also had to port our protoc changes and traffic stack just to serve this one app. This despite being a central part of our upmarket strategy. Ultimately it was completely rewritten. And nobody regretted that decision. We carefully weighed the pros and cons. There's something to be said for a company that standardizes on one or two languages. Letting engineers have free reign leaves you with Haskell and Erlang littered in important places, with a very tiny bus factor.

kazinator 4y ago

Why only an unhip, old geezer would write outdated drivel like: const int MAX_SIZE = 1024; const int HEADER_SIZE = 128; set_content_size(HEADER_SIZE - MAX_SIZE);

ncmncm 4y ago
Probably less geezery to write set_content_size(MAX_SIZE-HEADER_SIZE); Sayin'.
- kazinator 4y ago
  Never mind the operand order; what do we gain by using constexpr instead of const? In C++, const int x = 3 is already a constant. As of C++98 already, you can use x as a case label in a switch statement. It cannot be any more constant. Not cool any more?
  - ncmncm 4y ago
    You just want to ensure they don't take up space in your struct body. Otherwise, const is fine.

togaen 4y ago

These slides are profoundly uninteresting.

f1shy 4y ago

Honest question, do not want to insult anybody: I've heard lots of times, that the reason why C++ sometimes is weird and complex, is because utter care is taking in maintaining backward compatibility. Sorry if I'm wrong, but I remember seeing a video about variable initialization, which showed many ways of initializing variables, and at the end, the excuse was "all because we have to maintain compatibility to C". No my question, again, please do not think I'm insulting anybody: This presentation seems to show the compatibility between most recent releases is not very good. What am I missing here?

mrazomor 4y ago
The presentation mostly lists warnings and notices about deprecation. If you turn them all off, most likely the compilation would pass. So, backwards compatibility is there (if we ignore newly introduced keywords).
MauranKilom 4y ago
> This presentation seems to show the compatibility between most recent releases is not very good. Half of the "features" shown in the presentation are exceedingly niche. It's just that a 20 million LOC (or however many Chrome has right now) code base is almost guaranteed to exercise every niche feature somewhere. Having helped with C++ standard transitions of a code base half an order of magnitude smaller, the amount of issues requiring code changes was minuscule so far. You tend to have much more boring problems, like: - "We can't use newer C++ because C++/CLI doesn't support it" - "We can't use newer C++ in these headers because they end up included in CUDA code, and that compiler only supports C++14" - "We have to wait for a new version of <tool> before we can lint/sanitize/profile/format our code" - "This third-party code has the compiler up in arms now because it does questionable things"
- pjmlp 4y ago
  Yep, C++/CLI is stuck on C++17, and apparently will stay like that.

sbf501 4y ago

Slide 37: can't even use ++ anymore. Ouch. (at least on volatile, but still) Best line in the deck: "Only write complicated code when you truly need performance. Comment if you do...."

camdenlock 4y ago

I’m usually somewhat critical of Rust… but not when I encounter C++. What an over-engineered shitshow. Rust looks like a simple set of useful tools compared to C++’s convoluted warehouse of horrors.

ncmncm 4y ago
What you don't use, you don't understand.

WalterBright 4y ago

I had a great time implementing a C compiler and embedding it in the D compiler so it can import C code directly. I keep toying with the idea of doing that for C++, but since C++98 the language has just gotten too complicated to reliably map onto D semantics.

humanrebar 4y ago
I have been thinking of this D non-feature when reading up on the Carbon approach. Do you have any takes on how Carbon could be successful on mapping to C++ when D considers it too much of a reach?
- WalterBright 4y ago
  I don't know anything about Carbon. But a reasonable approach would be to use an existing C++ compiler and intercept its ASTs.
Decabytes 4y ago
with import C what is the benefit of creating bindings to C libraries if you can just work with the C code directly?
- WalterBright 4y ago
  ImportC can handle the .h files and/or the .c files, as the user prefers.
- schveiguy 4y ago
  import C is not perfect. There are pieces of C that don't map directly to D. Such as #define constants and macros. That being said, it will make writing bindings a LOT easier, even though D already has direct binding to C functions.

r2vcap 4y ago

C++20 is hard, but Peter Kasting's presentation is really easy to understand. I learned a lot. Also, I don't understand why there are so many negative views on C++. C++ is a beast, but somehow you can control it, and C++ is too popular and still in use to be replaced by anything else in the near future.

account42 4y ago

> Problem: Early test showed release binary size increased by 0.9% (Win) I guess once again you do actually end up paying for what you don't use. > Solution: Don’t care? :( Would have been nice if they at least analyzed where the increase was coming from. Maybe operator<=>?