TIP: In current MVS2022, if you double click left ctrl, the inferred type will be displayed between auto and the name. It's a great tool for those who really wants to know the type of the variable but also wants a cleaner code. It's like you can alternate between inferred type and explicit type with one button.
Even though it got a bit off topic, I like the "you could do this, you could do that" part with using and typedef while explaining the use of auto to do something similar.
@@qatarking2498 means that you are using a reference of a string instead of making a copy of each string object for each iteration, that's would be so inefficient.
@@qatarking2498 & used at variable declaration is the 'reference' token in C++ In addition to the C 'get adress of' meaning everywhere else. so here, 'auto &string' means declare a variable reference of automatic type named "string" :) also, i think a for-range loop would have been a bad example of what he wanted to demonstrate since in that case, 'auto' refers to 'std::string' and he wanted to show how long an itterator can be
Good explanation. Good guideposts. I can still remember a long cursing session from an experienced C++ programmer colleague when C++11 came out. When we asked why, the short answer was: "auto". His opinion was that the possible abuse significantly outweighs the benefits. (Perhaps, by time, he stopped having allergic reactions.)
I'm a huge typedef fan when templated code results in messy or confusing typenames. I don't use auto very often, but I do like your usage for iterator typenames. In those cases, the auto keyword is unlikely to get you into any trouble. I think in most other cases, it actually IS likely to get you into trouble. It is a useful tool to help dig your own grave.
Nice explanation. One other use-case for auto is when migrating your C++ application to 64 Bit I would prefer auto over types like unsigned int that could behave in a different way for 32 Bit vs 64 Bit compilation.
I like "auto" (and its variants in other languages) for when the actual type is of little or no interest to me (though I generally avoid it for basic types), and the times the actual type is of no interest is when the algorithm itself is far more important than the actual types involved. Also, "auto" should be considered mandatory when the type is explicit elsewhere in the line (result of a cast, new, etc), but I don't consider 5.0 or 5f to be sufficiently explicit.
std::unordered_map is just like a dictionary in python. That means it contain key , values pair: eg: std::unordered_map dict={ {"one",1}, {"two",2}}; std::cout
*My takeaways:* 1. *auto* could automatically work out what's data type suppose to be 0:11 2. When we might not want to use *auto* 5:04 3. A better way to use *auto* 8:58
How can I click "Like" on all your videos at a time? Because your way of explaining the concept is so lucid that I can easily conclude I'm gonna like all your videos..Hands down 🙌
I know a lot about C++, but still some stuff like auto is new. My BIG use so far of it, is to create a language. This language will later have so much features that it needs to have multiple languages to describe it, probably.
as far as i understand programming is a big thing and you can't just learn C++ in 2000 and never ever learn anything new, because there are gonna be updates, there are gonna be new libraries, and other stuff. so it is not weird its new for you even though you know lots about C++
I personally prefer to use 'auto' only in prototyping and research purpose. When I tests some stuff, 'auto' is kind of a quick way to do and try stuff. But once i finished to test and i'm actually working on a real project, i do preffer to use real types (or typedef/using for types that are really long or that mignt change in a future version). Also, typedef helps to change a whole ABI as well, but still restraining varibles to a single type. So changing types remains really easy that way :)
That seems quite useful for prototyping. You know, a quick and dirty, short piece of code as POC, test if an idea works, then replace "auto" with proper types.
I also really like knowing my types and being explicit. Many people think C++ is too verbose, but I think it helps in bigger projects. In languages like Python you will often see a ton of comments instead, telling you what types a function is expecting etc. I quickly becomes as long or longer than C++ code, which is self documenting to a certain degree.
I like the different possible options to do something ! so I can use auto, typedef or even define ! but auto is a nice feature and it absolutely simplify things. Like small embedded projects that are easier to debug and also with using it, the code would be less prone to have errors or warnings.
I think a better rule of thumb would be that you should specify the type explicitly when you need to know the type explicitly, and use auto when you don't, which is almost all the time really. It's still a strongly typed language, so the compiler will still make sure everything is correct. The idiom of using auto is common enough in the C++ community that it has a name, AAA, or Almost Always Auto. A real benefit to using auto even when the type is short is that implicit conversions are not allowed - so if the API changes and you have auto, there won't be unnecessary conversions all of a sudden, where there might be if you specified the type manually. Not a whole lot can be done to address the problem of needing to manually look up the type when you use auto, except that in my experience, it's much rarer to need to do that than it would seem at first glance. My recommendation would be to give both my and Cherno's strategies a go and see which you like - it really isn't *that* important which you choose. It will probably come down to what kind of work you do. I've done a lot of refactoring, and when a code base doesn't use auto, it tends to become a mindless task of changing the type to match the new type when auto would have just worked correctly, as well as unintended performance and correctness bugs from surprising type conversions that auto would have avoided.
As a Kotlin developer, I have to say this is not an issue to not specify the type and just infer it, from the perspective that you can't read the type when you take a look at the declaration. The IntelliJ Idea has a feature that lets display the inferred type (in Kotlin). There is maybe a plugin to let display the inferred type in visual studio. This is more an tool problem than a language feature problem.
I don't know before but, in MVS2022, if you double click ctrl it shows you the infer type before the var name, just like IntelliJ. I think C++ devs have a tendency of been extra careful with types, for understandable reasons, but auto can be helpful for a cleaner code.
On my team, we have a rule. If you use Auto, you need to have a VERY VERY VERY good reason to do so. As, personally, I like "self documenting" code, where I can debug something sometimes just by following it through. Usually, I can spot a bug just because auto has been used (coder thinks its a float, but it's an int, or something)
I know you would probably not use smart pointers, but what would you write: std::unique_ptr obj_ptr = std::make_unique(whatever); auto obj_ptr = std::make_unique(whatever); I am asking because std::unique_ptr is not that long, but for me it seems quite redundant, since the std::make_unique already tells the exact type
auto is a blessing - espacially when you need to declare iterator for std::list of std::map - and thank the holly c++ standard committee for "for(auto a : list) :)
could auto be interesting when doing math-functions on mathematical operations? Like you could pass either doubles, floats, or ints to them? auto SomeFunction ( auto aNumber, auto anotherNumber){ auto result = do some fance math; return result; }
You have to decide whats the biggest time saver....not typing the huge data type three times in your code.... or not having to play Sherlock whenever you maintain the code or explain it to others
could auto be interesting when doing math-functions on mathematical operations? auto SomeFunction ( auto aNumber, auto anotherNumber){ auto result = do some fance math; return result; }
I think there would be a problem with this even if it does work in precision or simply deducing the type. Because of the different number of trailing points, Or even in big numbers where if a double and a double are multiplied and return type is an int we lose precision.
Anything that is implicit is sort of bad, because it assumes some additional knowledge, and you have to think about multiple things at the same time when looking at it. Auto is such a thing, and the pointer-to-char constructor of the string class is another, which is mentioned in this video. I would just avoid these things if possible. I think perhaps they introduced auto to make the language seem more appealing compared to loosely typed languages, but if they really wanted to allow loose typing in C++, they should've tried to get rid of the auto keyword entirely (which would break a lot of things). I suspect auto will end up on lists of regret eventually.
'auto' isn't "type erasure" but "type INFERENCE". I see it as a convenience feature. C++ is still very strongly typed. It is just that you don't need to specify the type in places where the compiler can infer it. For C++ to lose its strong typing, you should be able to use "auto" for function params in its signature, or member variables. You can't.
Instead of having to write string you can write auto... Fantastic... You save 2 chars. With int you even use extra chars. A keyword like this has its uses but if you're declaring an int... Just declare the int. If it is absolutely assured to stay an int at least
My compiler disagree's with the char* returning a "Cherno". Any ideas why. I assume its because I am on a different C++. I believe I am on C++13 but not sure. In fact it causes two errors one on name.size() and the other on the char*.
he's probably building up to it. he only introduces one concept per video. which is fine, since people wanting to learn about auto don't automatically want to learn about lambdas. i, for instance, use auto to skirt around the stl's seeming hatred for memorable names.
In a language that's overwhelmingly verbose by default, they add a feature that enables you to type less and program faster, then all of the sudden there's a bunch of pseudo programmers mad at you because, according to them, with today's IDEs, they "can't figure out the type of the variable". OH COMMON!
I was hoping you'd talk more about the "dark side" of auto ^^ you know, the stuff you mentioned in the end , how it can work with templates etc. But the video was still pretty useful . Up to now whenever I came across code that used auto I was never really sure what the reason for using it was. This helped clarify that a lot of it is just for convenience purposes.
What's the plug-in/extension that you use to show the actual type of auto when hovering the cursor on the variable? Is it available for VScode on macOS? Thanks!
Hi char *GetName() { return "Hello"; } this is a bot confusing. Won't this be destroyed when the scope ends? Can you return a pointer to an array on stack? Can you please explain how can a function return reference? It is very confusing.
I NEVER use things like auto (or var in C#) Why ? Auto location = GetLocation(); So tell me, what is the type of location in this statement? That is why !
I think the only time I've ever used auto is when I used auto specifically just so that I could use auto because I never had before. I very quickly changed it away from auto because it didn't help anything at all.
You should avoid auto unless it's very obvious what the type is. Auto can make mistakes and it's not obvious to the next programmer what the type is supposed to be. It goes against strongly typed language ideology. This is kind of like a dynamic type during compile time.
TIP: In current MVS2022, if you double click left ctrl, the inferred type will be displayed between auto and the name. It's a great tool for those who really wants to know the type of the variable but also wants a cleaner code. It's like you can alternate between inferred type and explicit type with one button.
That's why I love this series so much. Firstly learned from the video itself, then learned from comments to grab new features.
This has been updated to alt+f1 instead of double ctrl in newer versions
Even though it got a bit off topic, I like the "you could do this, you could do that" part with using and typedef while explaining the use of auto to do something similar.
I'll be spending the next few weeks watching your videos and brushing up my C++ skills. Thanks for sharing your knowledge!
How did you brushing up?
you can simplify the for-loop even more to:
for (auto &string : strings)
readability over 9000
It is better to do for(const auto &string : strings)
@@qatarking2498 means that you are using a reference of a string instead of making a copy of each string object for each iteration, that's would be so inefficient.
He mentions for-range loops in the video and says it will be covered later in the series
@@qatarking2498 & used at variable declaration is the 'reference' token in C++ In addition to the C 'get adress of' meaning everywhere else. so here, 'auto &string' means declare a variable reference of automatic type named "string" :)
also, i think a for-range loop would have been a bad example of what he wanted to demonstrate since in that case, 'auto' refers to 'std::string' and he wanted to show how long an itterator can be
Be careful that you don't write that loop when using namespace std; then you'll be overriding the name of the string variable inside the for loop.
I feel blessed for finding this channel. Thank you man. I mean a lottttt.
Hi how far have u reached with C++ now that it's already 2 years passed
Hey, theCherno! Greetings from Romania, you're my first choice when comes to C++ tutorials. Nice job!
la fel))
I use auto to drive to my work
I use my drive to auto work
I auto drive my work to use
auto_comment(!=creative){};
My auto broke, so now I can't work...
I work auto to drive home
You know the day is gonna be good when cherno uploads a video
15:00 How I feel about c++
LMAO!!! 6 months later, how you feel now?
@@godnyx117 You know why programmers have 2020 vision?
It's cause they C++
I still don't feel what you feel.
Almost a year. How are you now?
4 years later, do you still agree?
Good explanation. Good guideposts.
I can still remember a long cursing session from an experienced C++ programmer colleague when C++11 came out. When we asked why, the short answer was: "auto". His opinion was that the possible abuse significantly outweighs the benefits. (Perhaps, by time, he stopped having allergic reactions.)
I'm a huge typedef fan when templated code results in messy or confusing typenames. I don't use auto very often, but I do like your usage for iterator typenames. In those cases, the auto keyword is unlikely to get you into any trouble. I think in most other cases, it actually IS likely to get you into trouble. It is a useful tool to help dig your own grave.
Nice explanation. One other use-case for auto is when migrating your C++ application to 64 Bit I would prefer auto over types like unsigned int that could behave in a different way for 32 Bit vs 64 Bit compilation.
Use size_t for this. That is its purpose
just use int64_t bro.
I like "auto" (and its variants in other languages) for when the actual type is of little or no interest to me (though I generally avoid it for basic types), and the times the actual type is of no interest is when the algorithm itself is far more important than the actual types involved. Also, "auto" should be considered mandatory when the type is explicit elsewhere in the line (result of a cast, new, etc), but I don't consider 5.0 or 5f to be sufficiently explicit.
11:00 Careful there, not sure whether constness, references i.e. & amp, are not conveyed in raw auto usage. 13:30 Exactly...
again a great episode !! clear and full of real code experience !! Thank so much!!
std::unordered_map is just like a dictionary in python. That means it contain key , values pair:
eg:
std::unordered_map dict={
{"one",1}, {"two",2}};
std::cout
thanks man.
*My takeaways:*
1. *auto* could automatically work out what's data type suppose to be 0:11
2. When we might not want to use *auto* 5:04
3. A better way to use *auto* 8:58
Should be pinned
Thanks for your great explanations. It would be great if you talk about lambdas and assertions in C++14 :)
Really good video. A suggestion on what to make next: Data structures 😀
How can I click "Like" on all your videos at a time? Because your way of explaining the concept is so lucid that I can easily conclude I'm gonna like all your videos..Hands down 🙌
1:40 auto for lambda variables is tremendously helpful... But if you need a specific base template type, might not be a good use for auto.
I know a lot about C++, but still some stuff like auto is new. My BIG use so far of it, is to create a language. This language will later have so much features that it needs to have multiple languages to describe it, probably.
as far as i understand programming is a big thing and you can't just learn C++ in 2000 and never ever learn anything new, because there are gonna be updates, there are gonna be new libraries, and other stuff. so it is not weird its new for you even though you know lots about C++
Talking about templates .....
You said there will be many more videos on templates ... you could make that next !!
SimGunther Hello Haskeller :D
Thay are in the game engine series
I personally prefer to use 'auto' only in prototyping and research purpose. When I tests some stuff, 'auto' is kind of a quick way to do and try stuff. But once i finished to test and i'm actually working on a real project, i do preffer to use real types (or typedef/using for types that are really long or that mignt change in a future version). Also, typedef helps to change a whole ABI as well, but still restraining varibles to a single type. So changing types remains really easy that way :)
I was just about to write that auto is so nice when working with itterators for crazy collections :)
two years ago of creating this video.
Happy new year cherno!
That seems quite useful for prototyping. You know, a quick and dirty, short piece of code as POC, test if an idea works, then replace "auto" with proper types.
I also really like knowing my types and being explicit. Many people think C++ is too verbose, but I think it helps in bigger projects. In languages like Python you will often see a ton of comments instead, telling you what types a function is expecting etc. I quickly becomes as long or longer than C++ code, which is self documenting to a certain degree.
Or just use type hints instead of comments.
I like the different possible options to do something ! so I can use auto, typedef or even define !
but auto is a nice feature and it absolutely simplify things. Like small embedded projects that are easier to debug and also with using it, the code would be less prone to have errors or warnings.
I think a better rule of thumb would be that you should specify the type explicitly when you need to know the type explicitly, and use auto when you don't, which is almost all the time really. It's still a strongly typed language, so the compiler will still make sure everything is correct.
The idiom of using auto is common enough in the C++ community that it has a name, AAA, or Almost Always Auto.
A real benefit to using auto even when the type is short is that implicit conversions are not allowed - so if the API changes and you have auto, there won't be unnecessary conversions all of a sudden, where there might be if you specified the type manually.
Not a whole lot can be done to address the problem of needing to manually look up the type when you use auto, except that in my experience, it's much rarer to need to do that than it would seem at first glance.
My recommendation would be to give both my and Cherno's strategies a go and see which you like - it really isn't *that* important which you choose. It will probably come down to what kind of work you do. I've done a lot of refactoring, and when a code base doesn't use auto, it tends to become a mindless task of changing the type to match the new type when auto would have just worked correctly, as well as unintended performance and correctness bugs from surprising type conversions that auto would have avoided.
I aspire to make a list of all Charno's 'don't-use' coding styles and request a code review from him.
Smart pointers, and here we have these.
_They're slowly making it JavaScript 🤣_
Great tut!
8:06
As a Kotlin developer, I have to say this is not an issue to not specify the type and just infer it, from the perspective that you can't read the type when you take a look at the declaration. The IntelliJ Idea has a feature that lets display the inferred type (in Kotlin). There is maybe a plugin to let display the inferred type in visual studio. This is more an tool problem than a language feature problem.
I don't know before but, in MVS2022, if you double click ctrl it shows you the infer type before the var name, just like IntelliJ. I think C++ devs have a tendency of been extra careful with types, for understandable reasons, but auto can be helpful for a cleaner code.
bless yo intelligent, puzzle solving soul
I wish you teach hashMap HashSet etc i see some so difficult examples and some simple ones
On my team, we have a rule. If you use Auto, you need to have a VERY VERY VERY good reason to do so. As, personally, I like "self documenting" code, where I can debug something sometimes just by following it through. Usually, I can spot a bug just because auto has been used (coder thinks its a float, but it's an int, or something)
you are really good in C++
thanks
I know you would probably not use smart pointers, but what would you write:
std::unique_ptr obj_ptr = std::make_unique(whatever);
auto obj_ptr = std::make_unique(whatever);
I am asking because std::unique_ptr is not that long, but for me it seems quite redundant, since the std::make_unique already tells the exact type
I think most programmers would use auto there.
The main reason I don't use auto is because it makes it impossible to detect integer overflows. I only use it for iterators.
auto is a blessing - espacially when you need to declare iterator for std::list of std::map - and thank the holly c++ standard committee for "for(auto a : list) :)
So when looking in a map this would be a good use too?
auto it = map.find(x);
if (it != map.end())
// do something
Will there be a performance difference between actual type and auto keyword?
I don't think so.. Because the type is always known at compile time.
i love chernos video, love from China
could auto be interesting when doing math-functions on mathematical operations?
Like you could pass either doubles, floats, or ints to them?
auto SomeFunction ( auto aNumber, auto anotherNumber){
auto result = do some fance math;
return result;
}
That is a sutuation for templates... :)
You have to decide whats the biggest time saver....not typing the huge data type three times in your code.... or not having to play Sherlock whenever you maintain the code or explain it to others
your english is amazing
Why wouldn't it be? Like he is English.
could auto be interesting when doing math-functions on mathematical operations?
auto SomeFunction ( auto aNumber, auto anotherNumber){
auto result = do some fance math;
return result;
}
Pretty sure you would use templates for that instead
I think there would be a problem with this even if it does work in precision or simply deducing the type. Because of the different number of trailing points, Or even in big numbers where if a double and a double are multiplied and return type is an int we lose precision.
Anything that is implicit is sort of bad, because it assumes some additional knowledge, and you have to think about multiple things at the same time when looking at it. Auto is such a thing, and the pointer-to-char constructor of the string class is another, which is mentioned in this video. I would just avoid these things if possible. I think perhaps they introduced auto to make the language seem more appealing compared to loosely typed languages, but if they really wanted to allow loose typing in C++, they should've tried to get rid of the auto keyword entirely (which would break a lot of things). I suspect auto will end up on lists of regret eventually.
'auto' isn't "type erasure" but "type INFERENCE". I see it as a convenience feature. C++ is still very strongly typed. It is just that you don't need to specify the type in places where the compiler can infer it.
For C++ to lose its strong typing, you should be able to use "auto" for function params in its signature, or member variables. You can't.
I don't see any way a compiled language can ever be weakly typed.
1:24 am not gonna take 10 mins
*takes 17 mins
Great!
can auto replace template?
hi, can auto replace template? i am new to c ++ :(
I cannot get the deduced "auto" type(int,char etc.) by compiler with mouseover in VS code(3:00) Is it an extension feature?
Another great video brother. But you missed the fact that we can't use auto without initializing it(I think).
Thanks for the great series.
@Borislav Kamenov it's interesting. But how?
@Borislav Kamenov Yeah brother, C++ does not allows to use it without initialisation.
I am gonna watch all videos!!!!
Great video, it is basically like an automagic.
never seen a for loop like the one you did
i normally use
for(int i = 0; i < strings.size(); i++)
{
// do things
}
I normally use something shorter. Since C++11, it is recommended way to iterate through the container.
for (auto& s : strings)
{
// do things
}
all was ok until probably episode 40-50, now it is becoming ... too fast and too difficult ;) still 50 to go
Instead of having to write string you can write auto... Fantastic... You save 2 chars. With int you even use extra chars. A keyword like this has its uses but if you're declaring an int... Just declare the int. If it is absolutely assured to stay an int at least
That works great, if you’re only using strings and ints. And you’re sure your interface will never change type and your not using lambdas
My compiler disagree's with the char* returning a "Cherno". Any ideas why. I assume its because I am on a different C++. I believe I am on C++13 but not sure. In fact it causes two errors one on name.size() and the other on the char*.
So auto is like the var variable in c#?
Thanks for your good job
Making vid about auto and not mentioning lambdas is a crime! ;)
Killzone Kid because templates ftw;)
he's probably building up to it. he only introduces one concept per video. which is fine, since people wanting to learn about auto don't automatically want to learn about lambdas.
i, for instance, use auto to skirt around the stl's seeming hatred for memorable names.
Yes, good point! I'll definitely mention that in the lambda video. :)
i use auto to declare a lambda functions
In a language that's overwhelmingly verbose by default, they add a feature that enables you to type less and program faster, then all of the sudden there's a bunch of pseudo programmers mad at you because, according to them, with today's IDEs, they "can't figure out the type of the variable".
OH COMMON!
I usually just use auto for function pointers or something where I don't know what the type is.
very good video. thank you!
Is this done during preprocessing stage or compilation stage
thanks for the video. You answered a few questions :)
thank you very much
Result!
so its basically How to turn C++ into Python
nr
So when do we use & with auto?
What is ur laptop specs
Normally use it with templates if the there's a possibility of different return types.
I was hoping you'd talk more about the "dark side" of auto ^^ you know, the stuff you mentioned in the end , how it can work with templates etc.
But the video was still pretty useful . Up to now whenever I came across code that used auto I was never really sure what the reason for using it was. This helped clarify that a lot of it is just for convenience purposes.
Very helpful, coding in java and needed a little translation.
What's the plug-in/extension that you use to show the actual type of auto when hovering the cursor on the variable? Is it available for VScode on macOS? Thanks!
it works for on vscode on linux
The video was helpful. Thanks.
will you also cover decltype(auto) at some point in the future?
OtakuNewb As it is part of the language surely.
Hi
char *GetName()
{
return "Hello";
}
this is a bot confusing. Won't this be destroyed when the scope ends? Can you return a pointer to an array on stack? Can you please explain how can a function return reference? It is very confusing.
I NEVER use things like auto (or var in C#)
Why ?
Auto location = GetLocation();
So tell me, what is the type of location in this statement? That is why !
You’re the best
So, i can determinate that keyword in C++ is like keyword in C#, JS, and now JAVA10?
Am i rigth?
Peterolen Thanks
I think the only time I've ever used auto is when I used auto specifically just so that I could use auto because I never had before. I very quickly changed it away from auto because it didn't help anything at all.
You should avoid auto unless it's very obvious what the type is. Auto can make mistakes and it's not obvious to the next programmer what the type is supposed to be. It goes against strongly typed language ideology. This is kind of like a dynamic type during compile time.
Elegancko
Can you make a video about move semantics?
Done 🙂
Thanks for this! Couldn't understand the concept no matter how much I tried, now I did! Cheers
so basically, auto in C++ is like var in javascript where it chooses the type for you? neat
Thanks. For the time being as a beginner auto adds a layer of opacity and is therefore best avoided.
Auto in C: 😭
Auto in C++: 🗿
ordered unordered map videos please sir Di Cherno!!!
Can you make a video on iterators?
Is that a Pixel 2 XL next to you on the couch ?
🙂
The Playlist for the C++ series is disappeard :-(
Did you say Welcome to 2020? 😋
Does auto helps in better memory management?
Thanks