Your way of teaching is really great...The Best...Not only this video but all of your series is great...
@mikewellner73456 жыл бұрын
Your C++ Videos are awesome. You should go on with em.
@jaewookim75036 жыл бұрын
I clearly understood the concept of move semantics only in 30 minutes! Which I couldn't understand clearly for 1.5 hour...
@aegisxiii23844 жыл бұрын
The key is to understand that move is not moving anything. It just flags it as a movable value so that you can redirect it into the proper function.
@alexanderdorfman79147 жыл бұрын
I really appreciate the video, it was great. Thank you ! Alex from UPS.
@antiHUMANDesigns4 жыл бұрын
3:10 You don't have to check if "i" is nullptr, you can use operator delete on a nullptr and it won't do anything bad.
@Joda-Tichicha2 жыл бұрын
Is always good to check whether the ptr is null or not before any uses
@antiHUMANDesigns2 жыл бұрын
@@Joda-Tichicha If a pointer is null, "delete" won't do anything, so there's no need to check it. That is, the "delete" operator will check if it is null for you, so you don't have to _also_ do it.
@tomaspyth70176 жыл бұрын
Your video is really music in my ear... Very well structured, I really enjoyed it.. Thx a lot and keep the good work....
@pdd35 жыл бұрын
Dude, you're freaking awesome. I hope you know that.
@fanpeter-z3c3 жыл бұрын
bro, best explanation so far on the internet !
@amrtcpp62034 жыл бұрын
I really appreciate you ,the video was full of information which i need. Thank you!
@LowellBoggs Жыл бұрын
The vector clear() method does depend on the contents of the vector because it calls the destructor on each element in the vector and then releases the buffer holding them. So it cannot be that you can clear a vector in an unspecified state - better to just leave it alone and let the compiler deal with it. Still, i am guessing the compiler has done the needful for the vector's destructor to work.
@burakcopur38417 жыл бұрын
"Fundamental Concepts in Programming Languages", I think this paper by Christopher Strachey is a gentle introduction to theoretical part of programming languages which helps to clarify all these C++ concepts. It also introduced the idea of lvalues and rvalues, ad-hoc and parametric polymorphism etc. I guess in 1967.
@vatnax26804 жыл бұрын
Bunch of useful information! Thanks!
@QuackersForMath5 жыл бұрын
This has been so helpful, and you explain it all really well :) Thanks!
@jamesvespa15 жыл бұрын
Thanks for this - makes the whole thing so much clearer.
@wolfram74114 жыл бұрын
Well done!
@lukask.34652 жыл бұрын
you should teach seriously, very well explained!
@Ewolf494 жыл бұрын
Seriously great video...
@dnavas77196 жыл бұрын
Amazing teacher. Thanks a lot.
@jlxip4 жыл бұрын
Great explanation, thank you!
@marcos-bl8ny3 жыл бұрын
Thanks a lot, great explanation
@RobinMs56 жыл бұрын
very good explanation
@MrGreeneyes776 жыл бұрын
These videos are truly great! I just wish the font was slightly smaller so you didn't have to keep scrolling up and down over and over...
@unusualfashion6 жыл бұрын
Sorry about that! I was actually more worried about the opposite problem of having text that was too small and uncomfortable to read in a video. Maybe I can find a happy medium in the future.
@Ewolf494 жыл бұрын
Damn, you’re good...
@jvsnyc6 жыл бұрын
Minor quibble. Regarding the new in C++ 11 "initializer syntax available everywhere and is now preferred". Originally I just thought it was terrific that I didn't need to create an otherwise unnecessary array in order to initialize my vector and other such blemishes in C++ 98 being removed. Then I thought "Great, now people won't keep confusing assignment with copy construction when they are sloppy or rushing, because we will always say TYPE var { initial value } instead of: TYPE var = initial value which sort of looks like an assignment but actually calls a constructor." At about 3:18 or so, you use the old syntax of copy constructor which calls a copy constructor but looks kinda assignment-y. Have you fully switched over to using { } syntax when calling copy constructors? I still sometimes find myself writing calls to copy constructors like that, but most modern C++ videos seem to totally avoid it because of the historical ambiguity due to looking like an assignment. Or because they only learned C++ recently and that's the way they always did it. I know both work, but this is a modern C++ video, so I think this may be a relevant point. Now back to your video.
@unusualfashion6 жыл бұрын
I've actually read on some other websites that {} has some problems in certain cases. Accidentally using aggregate initialization is one of them: struct Test { Test() = delete; Test(int) = delete; int i; }; int main() { //Test t1; //doesn't compile //Test t2(1); //doesn't compile Test t3{}; //i is 0 Test t4{1}; //i is 1 return 0; } To force a scenario where you can mistake something for a copy constructor is a bit more weird: struct Test { Test() : t1(*this) {} //weird: to initialize a Test& in a default ctor Test& t1; }; int main() { Test t1; Test t2{ t1 }; //not a copy ctor return 0; } This is more relevant when you're dealing with unknown types in templates. I don't use {} too often perhaps as a result of these types of problems. Maybe you could use std::is_aggregate to make sure you don't accidentally run into this problem, but that would be awkward. In any case, I'm not super strict about my usage of {}. Part of it comes from working in a large company where some people have adopted new styles/features and some haven't.
@jvsnyc6 жыл бұрын
Very interesting. While the hazards don't look like they would be super-common, they also don't look like they would never happen. I will continue to appreciate its availability for initializing vectors and maybe tend towards it in general but think twice about it as totally replacing all old-syntax calls to Ctor(const type &rhs)
@MJALI965 жыл бұрын
Would you need to free resources of Foo f (if any) before assigning it to a new object using the Rvalue Assignment Constructor? Consider the following: Foo f; { f=Foo(5); }; f now stole the resources of Foo(5). But would this create a memory leak if f already had resources.
@jvsnyc6 жыл бұрын
Regarding lvalues and rvalues early in the video. I would completely avoid showing 1 + 1 = 2 for the following reason. We get bit by the meaning of "=" in C/C++/etc. etc. as the assignment operator which mathematicians like Wirth and Dijkstra always hated, because for 600 years "=" meant what we now use "==" for in these languages. If we were using a language that used ":=" for assignment it would be different, but we aren't. Secondly, people need to get away from thinking of lvalues as things appearing on the left hand side of an assignment and rvalues as things appearing on the right hand side of an assignment, even me. It might be best to just say "we used to think of these as which side of an assignment they were on, but really what we mean is that an lvalue always has an address and an rvalue either has none at all because it is a pure temporary, or has one for just a moment but it is about to expire so we treat it as if it didn't....
@unusualfashion6 жыл бұрын
I think that so long as the standard keeps referring to them as lvalues and rvalues I'm sort of obligated to explain it that way at least for historical reasons or if people want to look the concept by name. I think it's also a fine way to get people unfamiliar with it to understand quickly, but you're right that it wouldn't hurt to move people away from it right after that little analogy to math equations. At 9:30 I do mention what you suggested with the lvalue as having an address.
@jvsnyc6 жыл бұрын
Yes, I watched and enjoyed the video and you also make some small but relevant points that several other videos that I have watched which try to cover the same material omit, including deep insight into lvalue vs. rvalue. Some people have trouble remembering which came last in a discussion, i.e. I will remember four years later the three ways we discussed that we might want to do something in a meeting on the topic, but I may forget which one we eventually agreed on. I will remind the other participants what the three things we discussed were and with that jog, one of them who didn't remember any of them before I refreshed their memory will tell me which way we decided. The best pedagogical method to dispel a common misconception is probably "a lot of people think this -- but no way, it's NOT THAT!" Definitely the "it is on the left-hand side of the equals sign" is a long ago accurate but still very common and no-longer productive way to think about it. The best SHORT way is, as you say lvalues have addresses, rvalues either don't have one at all or have one with a short fuse quickly burning down. After all this fuss, I actually think I'll never get confused about that again, although the subtle differences between lvalues/rvalues and lvalue references/rvalue references can still get a bit dodgy and require some ongoing attention.
@grolander7 жыл бұрын
Great video. Very clear thx
@alexandershirokov5 жыл бұрын
fantastic tutorials
@sourabhpandit59326 жыл бұрын
Good stuff!! But I could not understand why 2 move are required in last example,🤔
@unusualfashion6 жыл бұрын
When you std::move something to another function (which casts it to an rvalue reference) it acts like an lvalue reference inside that function. One reason why is that you may need to use that value more than once inside that function. If it stayed as an rvalue, it would be hard to use it more than once because the first time you use it it might have its resources stolen. So instead, you use std::move again inside the function to sort of indicate when that function is making its final use of the argument.
@jvsnyc6 жыл бұрын
I'm never crazy about having identical names for constructor parameters and members, and I have been looking for the best standard to adopt. I'm definitely not crazy about qualifying the member names with "this->" as I've seen in some videos, but calling the parameter, say, ii so the constructor initializer looks like i(ii) isn't really ideal to me either. However, the solution of using v both for the data member and the parameter indeed gets rather confusing right at the end of the video. "This is my cousin Daryl, this is my other cousin Daryl." That worked fine on that show (whichever it was) but that was as a joke.
@unusualfashion6 жыл бұрын
I mostly did it for the sake of brevity as the pace of the video depends on the speed at which I can type so short names are easier to work with. At work we use m_name for member variables and a few other things can appear on the left side of the underscore as well, such as 's' for static. No clue what the "best" standard would be, if there can be said to be one.
@jvsnyc6 жыл бұрын
If there were some quantitatively accurate way to measure programmer confusion, it would be the one that confused the fewest people by a Utilitarian standard. Even then, the definition should be made locally not globally, so whatever minimizes confusion on a team (or among those watching a video) would just be best. I have tried looking at the GSL, but every time I go in there I wander out a few days later, malnourished, dehydrated and sleep-deprived, having learned a million things I didn't go in to look for. In general in life I hate having one name for two distinct things one is talking about in a particular sentence, so the "not THAT v, I meant the OTHER v" rubs me the wrongest way of the different choices. Thanks for mentioning what you guys do at work, I think enough people do it that nobody would ostracize one for doing it...
@unusualfashion6 жыл бұрын
After fiddling with it, I'm somewhat annoyed that when changing this: struct Test { Test(int i) : i(i) {} int i; }; to struct Test { Test(int) : i(i) {} //name removed from parameter int i; }; that there isn't some kind of error. I was hoping that there was some rule that would prevent that so that seeing x(x) in the context of a member initializer list would be unambiguous. I don't know if there's maybe some good case for needing something like that... something like a class that needs a reference to something in its constructor and sometimes that something might be itself.
@jvsnyc6 жыл бұрын
hmmm...I was always taught that the only reason unnamed parameters were allowed in functions was to avoid unused variable warnings when an interface had been fully defined but no use was yet being made of that particular parameter in the actual code. That way even if one elevated warnings to errors the code would still compile without pragmas....The only other use of unnamed parameters I can think of is to differentiate prefix ++/-- from postfix when overloading. What you just showed looks pretty dangerous, someone could lose an i like that!
@MrGreeneyes776 жыл бұрын
I'd love to know which options you have set in VisualAssistX :)
@unusualfashion6 жыл бұрын
I believe I just have the default options on! Is there something in particular that's of interest? I also have a few other plugins, notably the Vim plugin which changes the way I move around the cursor and edit text a bit.
@sc5shout6 жыл бұрын
So if I have a custom STL vector class with copy ctor, copy operator, move ctor and move operator, to be more save I should say vector(vector&& src) { operator=(std::move(src)); } instead of vector(vector&& src) { operator=(src); } but it will not touch `vector&& src` anywhere inside this ctor. Does it make any difference or it is just a dignified way?
@unusualfashion6 жыл бұрын
You likely want to keep it as an rvalue as you pass it along. Perhaps it doesn't do anything specific to take advantage of the fact it's an rvalue now, but perhaps you will in the future.
@noway16756 жыл бұрын
what is the rvalue reference used for ?
@unusualfashion6 жыл бұрын
If you have a function that takes an rvalue reference to an object as a parameter, it could mean that it intends to do some optimization (relative to an lvalue reference) such as stealing the object's resource. You could have the function have two overloads, one for rvalues, where it does this kind of resource stealing, and one for lvalues, where it does something like a copy of the object instead. Then if you have an object that is temporary/expiring, you could use the rvalue overload as an optimization.
@videonrgntt6 жыл бұрын
First, thank You. Could You tell what version of C++ is in this video?
@unusualfashion6 жыл бұрын
You just need support for C++11 for what's shown in the video, though there was also probably good support for C++14 and some of C++17 in the Microsoft Visual C++ compiler at the time I made the video.
@shay79il6 жыл бұрын
Gr8 content :)
@MJALI965 жыл бұрын
Underated
@doonsmonk40795 жыл бұрын
I did the same program in VS2015 and if constructor and virtual destructor is defined then (move constructor ,move assignment operator, copy constructor and assignment operator are provided by compiler) . Program worked fine. ? if constructor ,virtual destructor ,copy constructor and assignment operator are defined then also (move constructor ,move assignment operator are provided by compiler) . Program worked fine.? But yes if we define move constructor ,move assignment operator then we have to manually define copy constructor and assignment operator.
@unusualfashion5 жыл бұрын
It may work fine in the cases you pointed out, certainly in terms of compilation, but depending on what's in your class, it may have incorrect runtime behavior. The rule of X is more about reminding you to handle certain situations that tend to involve constructors/destructors/assignment operators. The classic example is a class whose destructor deletes some memory it owns. In that case, when making a copy of an object of that class, we probably don't want both elements to point to the same memory, otherwise we'll double delete that memory when their two destructors are called. Following the rule of X helps us to ensure that we handle specific situations like these to avoid runtime errors. If you're making a virtual destructor just for the sake of inheritance, that's not really the same concern though, and you don't need to manually define the other things.
@huyvole97246 жыл бұрын
How to set Cursor like you (as Linux) on Visual Studio ?
@unusualfashion6 жыл бұрын
I'm using a Vim plugin for Visual Studio which changes the way that text editing is done quite a bit, including making the cursor look like that.
@karloes06 жыл бұрын
Good video, but the rule of three which you have explained at 17:50 is not correct. Before C++11 it was rule of three. With new standard rule of five was introduced. Generic definition would be: if you must define any of the special member functions you should probably define all of them. Also there is also mistake at 19:26. Standard says that move constructor and move operator can be generated (but there are rules for that). Not all compilers have this feature. I think that the Visual Studio 2017 compiler will generate them but one of the previous versions (2013 or 2015) didn't generated them.
@unusualfashion6 жыл бұрын
Oh, you're quite right. I made a big mistake there with the rule of three. At 17:50 I seem to be jumping ahead to how the existing three interact with the two new ones rather than explaining the rule of three properly. I'm not sure about your second point, at least judging by what is written here en.cppreference.com/w/cpp/language/move_constructor In the section about "implicitly-declared move constructor" it states that they will be implicitly declared if "all of the following are true" and includes "there are no user-declared destructors." It seems that although it may not be implicitly deleted, it won't be implicitly declared either.
@ammartamimi98642 жыл бұрын
this is bad coding when you let struct Foo do house keeping for a mess done outside the class/struct constructors. Foo has no clue if Foo::int* i pointing to new( ) or new[ ].
@Dziaji5 жыл бұрын
You confused const and rvalue. An l value can be on the left or right, and so can an rvalue.
@Joda-Tichicha2 жыл бұрын
i feel you checking another screen or something the examples are great but the way to you do it, it feels like dry no soul. otherwise all is perfect just try to give it more human sense or ambiance.