@@vladigr1 That's an option if you're the only one writing the code. Or when the entire team chooses to not use it. Otherwise you at least need to be able to read and understand the complicated stuff.
I've got one question: why the hell does "decltype((variable))" get deduced as a reference? Edit: Once I saw some of the other comments I think `(variable)` deserves its own episode on this channel.
@@BenjaminBuch That's what I thought but xvalues decay to an Rvalue refrerences while decltype((variable)) deduces an Lvalue reference. That's what confused me.
Both "var" and "(var)" are lvalues, it's just that decltype has a special rule for id-expressions. An id-expression is an expression that only contains a name. I can't post links but everything is explained in the page for decltype in cppreference.
@1:56 , Wouldn't it be more accurate to say that if a named object is passed to decltype, it will simply return the type of the object, while if an expression is passed, decltype deduces both the type and the value category of the expression based on its rules?
Sorry to sound negative, and I have longed for all the compile time richness that C++20 has for the past 20 years. But I hope decltype never sees widespread use.
this is `decltype` need support checking of type of expressions like `decltype(1 + 2)` and as C++ support code like `(i) = 42;` in this case `i` need be reference to allow assignment. To sum up, `decltype(i)` is "check what type given name have" and `decltype((i))` is "check what type of given expression is"
@@zamf "Is it because of C backwards compatibility?" Na, it is cause there is nothing that says it should not be supported. " `(i) = 42;`" is just a simple case of a more general usecase. This tiny snipped might seem pointless, but that is often the case with simple examples.
@@ABaumstumpf I've heard that allowing this kind of syntax leads to some very subtle bugs. For example: std::mutex m; void f() { std::scoped_lock (m); //you think you've locked the mutex but in fact you've created a temporary scoped_lock with the same name as the mutex and it does nothing } I don't see why anyone would use `(variable)` syntax either in declaration or in usage.
@@zamf technically, both i and (i) are references. They are only different when deducing return type. I believe the main reason they are different is to allow you to chose whether you want to include the "ref" or not. For example, if you have code like this (obviously you wouldn't, but for more generic code, you might): struct myClass { int a; decltype(auto) getA() { return a; }; }; You are now returning the value of "a", but if you want to return a ref to "a", you do "return (a);" If the code is very generic, you might not know whether "a" is a value or a reference, and treating "a" different than "(a)" gives you the flexibility to force the return type to be a reference. In a somewhat similar but opposite way, you can use "auto(a)" when passing to a const ref parameter to force a copy of "a" rather than using a const ref to "a" itself, if "a" might change during the executing of the function. So I believe this is just a feature of decltype to allow for fine tuning and flexibility rather than an effect of the language itself prior to decltype. I could be wrong about this though.
You need to configure your clang-tidy and tell it what to lint. If you have lsp supporting editor, like neovim or vscode, clangd is the language server you use. Clang-format is about intendation and stuff like that.
I haven't used UltraEdit in years. Didn't even know it was still being updated either. I think the last time I ever used it when I was still using Win98. It's not a bad editor, but at the time Crimson Editor was better. Looks like they added a bunch of features to UE and now Crimson is dead.
Okay this drive for always use auto just seems ridiculous. "Hey, we're a strongly typed language, but we want to give up the whole reason we're strongly typed -- so programmers know what the heck they're working with. But because we just obfuscated our code, let's add some more obfuscation to un-obfuscate the situation."
in the cases where you need decltype(auto) (in generic code, as strongly stated in the video) there is no viable alternative. It's a tool that exists for generic programming.
@@cppweekly One of the things I love about programming is that we have so many different tools and so many different ways to do things. And we can each find the tools that most fit our mindset. So it's okay when people disagree about the tools to use. Always Use Auto is an example of things we can disagree about, and that's okay. So maybe I really missed something, but I got the impression that we need decltype to make up for using auto. If it weren't for auto, we wouldn't need decltype. But I could just have entirely missed the entire point.
Wow C++ is so complicated these days. Great content by the way.
none forces you to used the complicated stuff.
@@vladigr1 That's an option if you're the only one writing the code. Or when the entire team chooses to not use it. Otherwise you at least need to be able to read and understand the complicated stuff.
C++'s accommodations for generic code are wild.
I've got one question: why the hell does "decltype((variable))" get deduced as a reference?
Edit: Once I saw some of the other comments I think `(variable)` deserves its own episode on this channel.
The answer is at 6:55. "variable" is a simple lvalue, while "(variable)" is an expression which refers to variable.
@@BenjaminBuch That's what I thought but xvalues decay to an Rvalue refrerences while decltype((variable)) deduces an Lvalue reference. That's what confused me.
@@zamf I'm not completely sure, but I believe "(variable)" is a glvalue, not a xvalue. C++ value categories are tricky ^^`
Both "var" and "(var)" are lvalues, it's just that decltype has a special rule for id-expressions. An id-expression is an expression that only contains a name. I can't post links but everything is explained in the page for decltype in cppreference.
@@LEpigeon888 Thanks for explanation and link!
I would like to see an episode on the difference between decltype and declvar
I keep track of all the topic requests here: github.com/lefticus/cpp_weekly/issues/ Please add yours and vote on the others!
@1:56 , Wouldn't it be more accurate to say that if a named object is passed to decltype, it will simply return the type of the object, while if an expression is passed, decltype deduces both the type and the value category of the expression based on its rules?
Might've been good to show what people were using before decltype(auto), i.e. having decltype(appropriate expression here) frequently.
Yeah, kind of looks like creative abuse of reserved keywords until you stop to think where it's derived from. 🙂
thanks for this. decltype(auto) still confuses me. Well, until this video it did!
Love your content! You're awesome. Thank you 💌
Thank you so much this helped a lot!!!! You saved my life
Sorry to sound negative, and I have longed for all the compile time richness that C++20 has for the past 20 years.
But I hope decltype never sees widespread use.
decltype has been around since C++11 so it already has seen widespread use
As explained in this video, it is necessary because plain "auto" discards cv & ref qualifiers, so you need decltype to retain them.
@@treyquattro decltype(auto) is C++14 - and more and more edgecases and strange behaviours got added later on as well.
@@Dziaji Then don't use auto!
I don't really understand why i != (i). Why are the types different??
this is `decltype` need support checking of type of expressions like `decltype(1 + 2)` and as C++ support code like `(i) = 42;` in this case `i` need be reference to allow assignment. To sum up, `decltype(i)` is "check what type given name have" and `decltype((i))` is "check what type of given expression is"
@@von_nobody Why does C++ support `(i) = 42;` ? Is it because of C backwards compatibility?
@@zamf "Is it because of C backwards compatibility?"
Na, it is cause there is nothing that says it should not be supported.
" `(i) = 42;`" is just a simple case of a more general usecase. This tiny snipped might seem pointless, but that is often the case with simple examples.
@@ABaumstumpf I've heard that allowing this kind of syntax leads to some very subtle bugs.
For example:
std::mutex m;
void f()
{
std::scoped_lock (m); //you think you've locked the mutex but in fact you've created a temporary scoped_lock with the same name as the mutex and it does nothing
}
I don't see why anyone would use `(variable)` syntax either in declaration or in usage.
@@zamf technically, both i and (i) are references. They are only different when deducing return type. I believe the main reason they are different is to allow you to chose whether you want to include the "ref" or not. For example, if you have code like this (obviously you wouldn't, but for more generic code, you might):
struct myClass {
int a;
decltype(auto) getA() {
return a;
};
};
You are now returning the value of "a", but if you want to return a ref to "a", you do "return (a);"
If the code is very generic, you might not know whether "a" is a value or a reference, and treating "a" different than "(a)" gives you the flexibility to force the return type to be a reference. In a somewhat similar but opposite way, you can use "auto(a)" when passing to a const ref parameter to force a copy of "a" rather than using a const ref to "a" itself, if "a" might change during the executing of the function.
So I believe this is just a feature of decltype to allow for fine tuning and flexibility rather than an effect of the language itself prior to decltype. I could be wrong about this though.
What is the best tool to lint C++ code, and catch things like parenthesis after a return statement, and enforce other best practices?
clangd?
@@PaulMetalhero Honest question, does it have a best-practices linting mode?
Also check the FAQ page
You need to configure your clang-tidy and tell it what to lint. If you have lsp supporting editor, like neovim or vscode, clangd is the language server you use. Clang-format is about intendation and stuff like that.
I want to talk about casting a lambda into a function pointer, and it's conditions
But i think you're better presenter than me.
Can you do it?
I an episode tracker to help me keep track of viewers' requests. Please add yours here: github.com/lefticus/cpp_weekly/issues/
I haven't used UltraEdit in years. Didn't even know it was still being updated either. I think the last time I ever used it when I was still using Win98. It's not a bad editor, but at the time Crimson Editor was better. Looks like they added a bunch of features to UE and now Crimson is dead.
Works well!! DANKEEE
it work on my pc thx bro vеry much
thank you bro thank you
your ti to explain sotNice tutorialng
I dоwnloaded everything is okay
god
Just don't use auto as the return type (write the real return type) and you don't need decltype(auto)!
th-cam.com/video/_x27Sz-QkZM/w-d-xo.html
As stated in the video and in other replies - this is a tool for generic programming. When in generic programming you don't know the return type.
C++ is outrageous lmao.
9 minutes of why C++ is such a horrible language! Great vid as usual :)
th-cam.com/video/_x27Sz-QkZM/w-d-xo.html
Okay this drive for always use auto just seems ridiculous. "Hey, we're a strongly typed language, but we want to give up the whole reason we're strongly typed -- so programmers know what the heck they're working with. But because we just obfuscated our code, let's add some more obfuscation to un-obfuscate the situation."
in the cases where you need decltype(auto) (in generic code, as strongly stated in the video) there is no viable alternative. It's a tool that exists for generic programming.
@@cppweekly One of the things I love about programming is that we have so many different tools and so many different ways to do things. And we can each find the tools that most fit our mindset. So it's okay when people disagree about the tools to use.
Always Use Auto is an example of things we can disagree about, and that's okay.
So maybe I really missed something, but I got the impression that we need decltype to make up for using auto. If it weren't for auto, we wouldn't need decltype. But I could just have entirely missed the entire point.
This syntax is like a bad joke. It is laughable that they thought adding garbage like this was acceptable in 2014.
So happy Rust and Carbon happened.
Rust is a different flavor of bad and bloated, but you're not willing to admit it :)
it work on my pc thx bro vеry much
thank you bro thank you