Live data from Hacker News

C++20, How Hard Could It Be

docs.google.com

71–80 of 444 posts

Re: C++20, How Hard Could It Be

#71
post #13

Earlier quoted context omitted.

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.

Anyone serious with TypeScript/JavaScript has many Eslint rules to keep the codebase sain.

[dead]

Re: C++20, How Hard Could It Be

#72
post #44
post #38

Earlier quoted context omitted.

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner,…

Editions only work for easy stuff, superficial grammar changes, and in a context where all dependencies are compiled from scratch with exactly the same compiler, aware of all editions. How many editions are rustc, rust-gcc, cranelift and whatever might come, being still kept up to date in 40 years (C++ age)? What about all the language changes that actually require semantic changes, how are epochs supposed to deal wi…

Rust is so trivially updated that claiming using the latest compiler is problematic almost sounds like a bad faith argument. Everyone in the Rust ecosystem updates withing a few days, because of how trivial it is.

Also if you go to GitHub and see a package that's not been updated in 5years, do you think enthusiastically "oh yeah, I'm gonna use this"? Because IMO, if it's not been updated in years, it's probably abandonware.

And another point is that I'm happy for them to deprecate/remove 40-year old (or less even) design decisions that have become outdated. Thinking all design decisions are immune to time decay like is foolish.

The ABI discussion is a bit worn out by now. Everyone will just tell you to use use C ABI if you need compatibility (until something better comes along?), And there's is a plethora of methods for all sorts of languages to help bridge language gaps.

Re: C++20, How Hard Could It Be

#73
post #62

Earlier quoted context omitted.

gcc is better than clang on every metric. Sorry, it's the facts. ¯\_(ツ)_/¯

Whoa, really? Since when?? After a lifetime of using GCC, I (like many others) moved to clang a few years ago, out of frustration with the slow development of GCC, a desire to use new C++ features, and stayed because of the superior error messages and, in my use cases anyway, superior code generation. In addition, I gather it's a much cleaner and easier to maintain code base. As a result, we get to have cool things l…

LLVM always delivers the cooler stuff I'll admit but GCC is ahead as an optimizing compiler, general lang support and generating cryptic messages.

Re: C++20, How Hard Could It Be

#75
post #38

Earlier quoted context omitted.

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner,…

> Rust does well on this front. Rust needs to exist for at least 20 years before you can say it "does well" on 20yo projects. > majority of users jump on it straight away This is a sign of a language with a tiny mostly-hobbyist user-base.

> This is a sign of a language with a tiny mostly-hobbyist user-base.

Or that the tooling is so trivially easy to update that people don't need to think about it. Sometimes if I want to upgrade GCC I need to upgrade the whole os, or have multiple versions installed and be careful where they're installed lest I incur Ubuntu's wrath

Re: C++20, How Hard Could It Be

#76
post #47

Earlier quoted context omitted.

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.

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.

umm, you can

edit: to elaborate both g++ and clang++ implement the Itanium C++ ABI[1]. You might get binary incompatibility by mixing standard libraries, so just don't do that.

[1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Re: C++20, How Hard Could It Be

#77
post #6

Earlier quoted context omitted.

They are experimenting https://chromium.googlesource.com/chromium/src/+/refs/heads/...

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/... ). That would be nice for next gen browser invention.

You can find some module candidates here 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

Re: C++20, How Hard Could It Be

#78
post #38
post #22

Earlier quoted context omitted.

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?

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner,…

Not true. I picked up a git repo 18 months old. I tried to set up my rust dev stack to match the version in cargo. Then hit a lot of issues with dependencies due to abandoned repos used for the crates. I gave up and moved on.

Re: C++20, How Hard Could It Be

#79
post #51

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?

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).

Re: C++20, How Hard Could It Be

#80
post #51

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?

> 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.

Post reply on HN