Timur Doumler - How C++20 changes the way we write code - Meeting C++ 2020

Timur Doumler - How C++20 changes the way we write code - Meeting C++ 2020
Slides: slides.meetingcpp.com
Survey: survey.meetingcpp.com

[@fredhair]

Having been learning web dev past few months I've not been able to keep up with the latest C++. This is a really nice video for getting a practical overview of many of the new features. Very useful examples and not too heavy on technical details, really great video

[@Michael_19056]

Regarding the example used for concepts, another solution exists which was not mentioned. `if constexpr` could also be used to disambiguate. Something like: template bool is_power_of_2(T input) { if constexpr (std::is_a_t) { // treat as option A } else if constexpr (std::is_b_t) { // treat as option B } else { static_assert(...) } } It might not be the best option but it is another way to solve the issue.

[@colinmaharaj]

Why not write a web server using C++ 20. You will be keeping up in both camps

[@vsevolodkvachev7649]

Every of these features is so awesome, it's just what I wanted, thank you C++ Standard Committee!

[@skratky]

The examples used in this talk are to the point.

[@simonfarre4907]

What I always wonder about co routines, is that, it's usually given examples like in this video of reading, lexing and parsing. To me, that example is counter intuitive. How does that not just utterly thrash the cache? It seems to me, that real parallalelism, not just concurrency, is almost always going to be better than this coroutine thing of switching contexts constantly, however, I might be thinking about it wrong, and perhaps I assume that the switching between contexts (coroutines) happens more often than it would do, when used correctly.

[@Maranello988]

It's mind-blowing when you start thinking about the freedom level which mentioned stuff might propose!

[@hamol3d]

Excellent presentation! Gold.

[@NoNameAtAll2]

Didn't know coroutines were released so raw

[@LEpigeon888]

38:10 I don't understand why the user passing a value for this template parameter would break anything. I mean, if it's a user-defined value or the default value it won't change anything, they will both compile without any issue.

[@leetom5192]

Seems to have a bug in the generator move assignment operator. It didn't check and release the LHS object's handle, and could cause problems.

[@solarcrystal5494]

since coroutines are on the heap, can they stack overflow or will they get out of memory ?

[@PL-VA]

This is the most obscure implementation of int f() { static int = 0; return i++; } I've ever seen.

[@RoyBellingan]

He said, static will introduce a global state. And he want to avoid that.

[@rolandinnamorato1953]

Want to avoid global state

[@jeffmcclintock]

OMG! why "co_yield"? now I have to painstakingly change all my variable and functions which are already in use which are also called "co_yield" ;) Why did the C++ Standards Committee make such a big mistake? They should have just made it "yield" like all other programming languages.

[@URTonemanclan]

c++24 "Dealing with stack smashing performance issues of too many coroutines..."

[@NoNameAtAll2]

Coroutines are on heap

[@simonfarre4907]

There is a few flaws with how range based for loops are written (in my opinion) and it relates to something I was trying to write an utility for. And that was a range based for, that returns a pair (or an anonymous struct, doesn't really matter) of {index, (*iterator)} (i.e. ) and it works - *kind of.* If I write for(auto [i, element] : enumerate(container)) it works - but nowhere can the user of that function, see that "element" is actually a reference to the element. To signal *such* an intent, one would typically in range-based for loops write (auto& [i, e] ...) but that resolves to a completely different problem; because the auto& does not mean that i and e are of type reference, but that the *returned object* is of type reference, meaning the object holding the reference to i and e. This obviously becomes a problem, because you can't change a reference referent, or what that reference is referring to. Which means, I would have to make another temporary class that instead looks like {size_t*, Container::pointer} - and this means, that within the for loop, we now have to use -> everywhere which *also* is counter intuitive with how range based for loops work. This is one of the many issues with C++ unfortunately. In other languages, they understood that reference could and should be used in the way I describe it, but since C++ retrofit these features (of range-based for) instead of completely rewriting it, we are left with this mess.

[@LEpigeon888]

So you're complaining that you get a reference when your type is a reference ? I don't see the issue here.

[@simonfarre4907]

@@LEpigeon888 It has to do with how the higher abstractions of the language work and it is an inherent flaw that unfortunately can't be changed, as it would break backwards compatibility. Range based for, is essentially a compiler macro, instead of it being a language feature. That was my point. To be more clear by what I mean in other languages you could write something like auto [i, &e] to take a reference to what e would destructure to.

[@OeHomestead]

I remember the good ol' days when C++ was less cryptic :-)