Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++20, How Hard Could It Be

docs.google.com

Post reply on HN
Print view View original

421–430 of 444 posts

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

#421

Post by ncmncm »

kccqzy wrote: post #397
int_19h wrote: post #385

Earlier quoted context omitted.

The idiomatic version has gotten faster since C++03 overall thanks to move semantics. std::unique_ptr doesn't have any overhead over Foo* in code where semantics is the same (i.e. you want to delete when going out of scope) on any sensible ABI - it has the same storage size, and all operations are trivially inlineable to the same exact thing you'd do with a raw pointer. About the only time I can think of where it can…

> std::unique_ptr doesn't have any overhead over Foo* in code where semantics is the same Not true. And you just refuted yourself by being up the ABI question. You should watch Titus Winters' presentation on this topic where he compiles code using unique_ptr and raw pointers, compares the assembler produced, and explains why unique_ptr has non-zero overhead. The overhead is indeed coming from the ABI. Google has been…

Not breaking binary compatibility is a pure good.

The standard could pull unique_ptr in as a built-in feature with a different name, and retain backward compatibility at cost of an unfortunate redundancy. Code using unique_ptr would gradually transition to the new thing.

Of course each would have a move constructor from the other, to ease the transition.

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

#422

Post by pkasting »

codeflo wrote: post #53

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 s…

Chromium compiles with -Werror, so deprecation warnings must be fixed before we can upgrade.

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

#423

Post by pkasting »

cletus wrote: post #116

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 restrictiv…

This is from Chromium's perspective, yes, but Chromium complies with the Google style guide. I disagree with your characterization that "a very restrictive subset of features" are allowed, though. What's banned is relatively limited, IMO: http://google.github.io/styleguide/cppguide.html

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

#425

Post by pkasting »

xyzzy4747 wrote: post #156

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.

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.

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

#426

Post by pkasting »

TinkersW wrote: post #21
butterisgood wrote: post #9

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

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.

Took a couple of months actually, but it's mostly complete now and we're starting to throw the switches.

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

#427

Post by pkasting »

TinkersW wrote: post #45
Matumio wrote: post #25

Earlier quoted context omitted.

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.

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

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.

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

#428

Post by Decabytes »

WalterBright wrote: post #368

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.

with import C what is the benefit of creating bindings to C libraries if you can just work with the C code directly?

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

#429

Post by tinco »

p1esk wrote: post #406
f1shy wrote: post #405

Earlier quoted context omitted.

Used yes. But not the biggest part. Maybe 10% at most. We are doing L4, so if something goes wrong, the manufacturer is responsible. Once we were in a test car. It was behaving great. At one point, the car "makes the decision" to accelerate and pass. The manager to which we were showing asks "we did the car not waited a little bit? can we change that behavior?". A very long discussion ensued, about data sets, labelin…

This is a good point, and I expect in the near future we will be able to simply ask a neural network to explain and change its behavior without retraining. I already see signs of that in prompt engineering used to interact with GPT3 or Dalle2.

It's just going to be as good as asking a human to explain its behaviour. It might be a semi-accurate interpretation of its actions based on its internal knowledge, but it's never going to be the actual thing. The actual decision making inside a neural network is fundamentally not something you could simplify into language exactly.

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

#430

Post by WalterBright »

Decabytes wrote: post #428
WalterBright wrote: post #368

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.

with import C what is the benefit of creating bindings to C libraries if you can just work with the C code directly?

ImportC can handle the .h files and/or the .c files, as the user prefers.
Post reply on HN