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

431–440 of 444 posts

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

#431

Post by p1esk »

tinco wrote: post #429
p1esk wrote: post #406

Earlier quoted context omitted.

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.

Yeah, it's not clear if we will be satisfied with those explanations: "I decided to slow down because I see these (seemingly random and irrelevant) objects around me", because during training on trillions of video frames the model has learned it should slow down when similar object configurations are present to reduce the chance of an accident by 0.0002%.

Even if the given reason is simple, like "I decided to slow down because the car in front of me is red", explicit override of the learned rule ("don't slow down when you see red cars") might potentially increase the chance of the accident by a lot more than 0.0002% because we are messing with the model decision making process.

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

#432

Post by gspr »

spoiler wrote: post #72
pjmlp wrote: post #44

Earlier quoted context omitted.

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

> Everyone in the Rust ecosystem updates withing a few days, because of how trivial it is.

I love Rust, but this attitude is terrible. Luckily it's also not accurate – it's perfectly fine to stay on your distro's compiler.

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

#433

Post by mgaunard »

munch117 wrote: post #93
mgaunard wrote: post #42

Earlier quoted context omitted.

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.

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.

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.

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

#434

Post by schveiguy »

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?

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.

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

#435

Post by munch117 »

mgaunard wrote: post #433
munch117 wrote: post #93

Earlier quoted context omitted.

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.

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.

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

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

#436

Post by arinlen »

polio wrote: post #179
cletus wrote: post #135

Earlier quoted context omitted.

You could focus on those 460 pages but I'll raise 2 points: 1. There's still a lot of complexity and ambiguity you can fit in 460 pages. This presentation notes one example of decrement operators on volatile variables being deprecated because the behaviour was undefined; and 2. Can you really separate the standard library from the language at this point? Things like move semantics depend on std. Does anyone actually…

Couldn't you still use move semantics without std::move? You'd just have to write your own cast to an rvalue-reference.

> Couldn't you still use move semantics without std::move?

That's correct, std::move is just syntactic sugar to cast objects to revalue references, i.e., the sort of object that is expected to be moved around.

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

#437

Post by arinlen »

cletus wrote: post #135
arinlen wrote: post #128

Earlier quoted context omitted.

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

You could focus on those 460 pages but I'll raise 2 points: 1. There's still a lot of complexity and ambiguity you can fit in 460 pages. This presentation notes one example of decrement operators on volatile variables being deprecated because the behaviour was undefined; and 2. Can you really separate the standard library from the language at this point? Things like move semantics depend on std. Does anyone actually…

> 1. There's still a lot of complexity and ambiguity you can fit in 460 pages.

That's a meaningless assertion and reads like a non-sequitur.

Your thesis is that modern C++ somehow became complex. Yet, the truth of the matter is that modern C++ is mostly comprised of formerly third-party libraries, initially released as part of the likes of Boost, that were since then added to the standard. The core language did received much needed improvements throughout the years, such as aggregate initialization with designated initializers, but the total sum of these changes barely grew the standard in around 5% of it's initial size.

Unless you come up with clear examples that you feel support your thesis, you'll have to scratch out your complains as irrational dislikes.

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

#438

Post by jnwatson »

qsdf38100 wrote: post #361
jnwatson wrote: post #153

Earlier quoted context omitted.

Did you see the original post? Lots of code changes were required for Chrome. That’s not backwards compatible.

It’s 99.9% backward compatible. The comment makes it sound like it’s a huge pain every 2 years, as if it was the "python 2 to 3" level of pain. I went through a lot of these new versions, starting with c++11, and can’t remember one time I had to change anything to my code based, appart from silencing deprecation warnings for unicode stuff. Now I get that chromium-like code bases are huge and that the 0.1% of backward…

I've done several Python 2->3 transitions, and the amount of effort looks to be in the same order of magnitude described in the post.

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

#439

Post by germandiago »

evouga wrote: post #307
tialaramex wrote: post #152

Earlier quoted context omitted.

Mostly deprecations mean something was deemed to be a bad idea, which means it's at the very least worth taking a moment to evaluate whether somehow they were a good idea when you did them. For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost…

The volatile parameters deprecation is one of the stranger decisions, though, since there are plenty of constructions that don’t do anything but are still allowed by the language. I see this as a matter of style that might be useful to warn about, but shouldn’t be policed as an error by the compiler.

FWIW it participates in overloading. Did you ever try to overload all combinations of teplate specializations? With volatile is even worse.

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

#440

Post by germandiago »

gravypod wrote: post #355
ncmncm wrote: post #319

Earlier quoted context omitted.

This sounds nice but is not true. The bigger the system is, the more value you get from exceptions. The cost is that cleanup operations have to be in destructors. Do that, and exceptions demand almost no attention. Problems show up only when some prima donna declares throwing exceptions from what they call isn't allowed.

(Opinions are my own) Google uses absl::Status / absl::StatusOr as a replacement for what people would usually use exceptions for. The benefits: 1. As an end user of a large library I can tell you exactly which calls are "guaranteed" to succeed without learning anything else about the code. 2. It is impossible to ignore a Status/StatusOr which makes it impossible to ignore a failure. You have to explicitly ignore the…

1. you usually capture the most general exception in a lib and avoid all refactorings derived of can/cannot fail deep in a stack of calls that needs to be propagated all the way up. With status it happens the same as with stackless coro. Once something is like that, you need to propagate it all the way up.

2. an exception cannot be ignored either.

3. you can transform an exception into a value or even code them as values.

4. See nested_exception.

Post reply on HN