CppCon 2019: Timur Doumler “C++20: The small things”

preview_player
Показать описание



C++20 comes with some big new language features: modules, coroutines, concepts, spaceship, and many new libraries. But apart from all those, C++20 also offers many small language improvements, making C++ more powerful and expressive, but also safer and more consistent.

This talk is an overview over all those smaller additions to the core language that will make your life easier. We will discuss much-needed improvements to existing facilities such as lambdas, CTAD, structured bindings, and initialisation, as well as brand-new language utilities that you may not yet have heard about!

Timur Doumler


*-----*
*-----*
Рекомендации по теме
Комментарии
Автор

Now you can truly have all of the brackets in a lambda []<typename T>(T param){ return param; }

kebien
Автор

Excellent talk and well explained all around!

zakeria
Автор

Can someone explain the cray cray syntax I can't grok how that's the correct syntax at all. But trying to "fix" the syntax to what I think makes sense doesn't work. So these looks like typos to me but aren't???

Even after decades, I don't understand C++ apparently. :(

In the capture list, why are the ellipses `...` BEFORE `args`? And why only on the first `args` but not the second??? I would have thought it should be:

[ f = std::move(f), args...= std::move(args...) ]

OR AT LEAST

[ f = std::move(f), ...args = std::move(...args) ]

But nope. Neither of these compiles. I'm so confused!

think
Автор

49:00 if you’re unsure of the evaluation, assign the result of square() to a constexpr variable to force the evaluation to be at compile time.

Bakuta
Автор

I really wish the committee would specify ONE initialisation convention as best practice and the compilers enforce it

lenkite
Автор

"You don't need "make" functions anymore"

Not quite true; in fact, for tuple and pair the deduction guides are nutty to the point where you're better off sticking with make_tuple and make_pair because they're much less likely to surprise you. For example, CTAD for a declaration of a tuple containing a single pair will invoke the user-defined conversion instead of building a tuple containing a pair, as you almost certainly intend. This makes CTAD for tuple and pair useless in generic contexts, which are the only contexts where using pair or tuple is a good idea anyway.

isodoublet
Автор

"We need a keyword for something that isn't const but is statically initialised" "Constinit" "Perfect!"
Would staticinit not have made more sense?

marinedalek
Автор

Anything language features in this talk get changed/dropped from C++20 since it was given?

PaulTopping
Автор

It makes no sense to put a `static` variable in a header. There will be a copy of the variable in each translation unit. Should be declared as `inline Colour` instead.

MikhailMatrosov
Автор

I'm pretty sure he's wrong about how constexpr functions work.

This is especially true when using is_constant_evaluated.

He says that the function will be computed at compile time if all the inputs are constexpr.

BUT I'm pretty sure it's only guaranteed to be computed at compile time when the function is called in a constexpr context.

I've checked it using a test program similar to what he has at 45:00:

int a = square(3); // runtime
square(3); // runtime
const int c = square(3); // compile time
constexpr int d = square(3); // compile time

guyben
Автор

54:57 Something I don't understand: the value of the cases can only be a value of the enum class (in this case rgba_color_channel), so why do you need to specify it in the first place and just omit it. I mean, the compiler should be smart enough to figure that out (and in Java I think that works).

kuhluhOG
Автор

Since the question if std::is_constant_evaluated() shouldn't use an if constexpr rather than if is so common, shouldn't we propose to just have any if constexpr condition that in someway relies on std::is_constant_evaluated() be converted to a normal if? I am hoping that all compilers will warn at least.

mfkman
Автор

would be nice if we had `if (consteval (variable))` where `consteval` is an operator like `noexcept`
instead of `if I'm not actually sure how you'd make that work tbh…
Just thought it'd be nice

LemonChieff
Автор

The square() function at 49:00 is really dreadful. So now you have a way for your function to behave differently depending on the not-so-trivial evaluation of constness of it? Good luck finding those bugs!

misium
Автор

using namespace is bad, and so will using enum be.
The solution for the switch is to just deduce the type of the variable.
I'm not going to use using enum.