at 15:25 isn't the move() call redundant to construct the vector m_v ? Since v is already an Rvalue reference, the move constructor would be called anyway, wouldn't it ?
Thanks for including a timestamp! A lot of people ask me questions and then I have to dig around in the video to figure out which part they're talking about. :) You actually need the call to move because v becomes an lvalue reference again inside the function (the constructor in this case). I agree that it's quite confusing as you can see the && right in the parameter list. Try to think of it as being bound to a new identifier (the name of the parameter, v) and it might help in terms of thinking of it as an lvalue again. Having it as an lvalue gives you the choice to treat v as an lvalue or decide to keep moving it around elsewhere (in this case to m_v's constructor).
@@unusualfashion oh I get it, thanks. Although, you mention that v becomes an Lvalue Reference, and since the type of vector isn't deduced by the compiler I can only see it being a plain Lvalue. In fact, clang confirms that v is of type std::vector. Am I missing something ?
@@enzoaguado2974 By way of documentation you're quite right. From here: docs.microsoft.com/en-us/cpp/cpp/rvalue-reference-declarator-amp-amp?view=vs-2017 "When you write a function that takes an rvalue reference as its parameter, that parameter is treated as an lvalue in the body of the function." The reason why I would also argue for the case of it being lvalue reference-like in terms of a mental model is that modifications to the argument inside the function will be seen in the object that was initially "moved into" the function, so that makes me think of it less as a plain (non-reference) lvalue.
But if Bar has vector do I need to use emplace_back? I use forward on make_unique but the emplace back gets a unique_ptr so no point in emplace_back right ?
at 2:48 when your showing the initial optimization to v1 with the move before you do the better optimization; I don't see how the move even optimizes pushing back f1 into the vector. the vector will still have to create and element that it stores doesn't it. I understood in the previous video with a pointer the class can save a call to new by just stealing the moved class' pointer; I only see this helping if f1 was a pointer that was initialized with new then we can steal that pointer and store it in the vector without using new to allocate memory? Can you show me how move helps in this situation.
push_back on vector has a variation that accepts rvalues and then creates the new element by moving data from the moved argument into the new element. In this particular example, for Foo I just wrote "//a lot of member variables" as its data. If any of them can take advantage of move semantics, then doing a move into the push_back could be useful, but if those member variables were something that don't really benefit from move semantics, like a bunch of integers, then it wouldn't make any difference. As you mention, a case where it could be interesting is if the constructor of Foo new'd some data, then moving it could be helpful.
It's the dark theme that comes with a plugin called Visual Assist. Seems like there's something similar here: marketplace.visualstudio.com/items?itemName=septag.visual-assist-dark
why did you stopped making c++ videos??? Please find time to make more videos, your videos are just awesome, Thanks
rightly said !
*He's fed up of typing!!!*
I think he is busy playing video games, judging from his other gaming videos.
Thank you for making those awesome C++ videos!! Please make some more if you are still interested in doing so :-)
remember, with perfect forwarding comes perfect responsibilities
what you did is unbelievable, thanks a lot.
Really well explained thanks
Great video!
great explanation thank you so much, I was wondering all my days to understand this concept. You made my day.
Thanks man, that was a really nice video.
Great content
at 15:25 isn't the move() call redundant to construct the vector m_v ? Since v is already an Rvalue reference, the move constructor would be called anyway, wouldn't it ?
Thanks for including a timestamp! A lot of people ask me questions and then I have to dig around in the video to figure out which part they're talking about. :)
You actually need the call to move because v becomes an lvalue reference again inside the function (the constructor in this case). I agree that it's quite confusing as you can see the && right in the parameter list. Try to think of it as being bound to a new identifier (the name of the parameter, v) and it might help in terms of thinking of it as an lvalue again.
Having it as an lvalue gives you the choice to treat v as an lvalue or decide to keep moving it around elsewhere (in this case to m_v's constructor).
@@unusualfashion oh I get it, thanks. Although, you mention that v becomes an Lvalue Reference, and since the type of vector isn't deduced by the compiler I can only see it being a plain Lvalue. In fact, clang confirms that v is of type std::vector. Am I missing something ?
@@enzoaguado2974 By way of documentation you're quite right. From here: docs.microsoft.com/en-us/cpp/cpp/rvalue-reference-declarator-amp-amp?view=vs-2017
"When you write a function that takes an rvalue reference as its parameter, that parameter is treated as an lvalue in the body of the function."
The reason why I would also argue for the case of it being lvalue reference-like in terms of a mental model is that modifications to the argument inside the function will be seen in the object that was initially "moved into" the function, so that makes me think of it less as a plain (non-reference) lvalue.
But if Bar has vector do I need to use emplace_back? I use forward on make_unique but the emplace back gets a unique_ptr so no point in emplace_back right ?
Yea. In your case with make_unique just using push_back is fine. push_back can operate on the prvalue unique_ptr returned by the make_unique.
why did you stopped making c++ videos???
he got piles
at 2:48 when your showing the initial optimization to v1 with the move before you do the better optimization; I don't see how the move even optimizes pushing back f1 into the vector. the vector will still have to create and element that it stores doesn't it. I understood in the previous video with a pointer the class can save a call to new by just stealing the moved class' pointer; I only see this helping if f1 was a pointer that was initialized with new then we can steal that pointer and store it in the vector without using new to allocate memory? Can you show me how move helps in this situation.
push_back on vector has a variation that accepts rvalues and then creates the new element by moving data from the moved argument into the new element. In this particular example, for Foo I just wrote "//a lot of member variables" as its data. If any of them can take advantage of move semantics, then doing a move into the push_back could be useful, but if those member variables were something that don't really benefit from move semantics, like a bunch of integers, then it wouldn't make any difference. As you mention, a case where it could be interesting is if the constructor of Foo new'd some data, then moving it could be helpful.
@@unusualfashion Thanks, I guess it just as it's described; move semantics takes advantage of moving data rather than doing extra copies.
Witch theme u use?
It's the dark theme that comes with a plugin called Visual Assist. Seems like there's something similar here: marketplace.visualstudio.com/items?itemName=septag.visual-assist-dark
thanks
Ping Pong match?