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

[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

[vsevolodkvachev]

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.

[Maranello]

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

[simonfarre]

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.

[NoNameAtAll]

Didn't know coroutines were released so raw

[LEpigeon]

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.

[solarcrystal]

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

[leetom]

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.

[PL-VA]

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

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

[OeHomestead]

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

[simonfarre]

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. <size_t, Container::reference>) 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.