Introduction to std::move in C++ | Modern Cpp Series Ep. 32

[@cameronrowe2032]

Two hours of awkwardly delivered obfuscating lecture in college, or 10 minutes with Mike - take your pick! Excellent explanation, as usual, Dr. Shah. Thank you!

[@MikeShah]

Cheers 🙂

[@catklyst]

Thanks! This genuinely clarified a lot and demonstrated the basics.

[@MikeShah]

Cheers, thank you for the generous donation!

[@kim4857-u7j]

So here the std::move here equals to static_cast, which means that the move semantic doesn't "move" the resource, it just converts the lvalue to an rvalue. The implementation of the move assignment operator actually "steals" the resources held by "myString".

[@MikeShah]

Correct, I should more explicitly state that around the 5:50 mark or so that 'std::move' is not really doing anything other than the cast as you say which allows us to call a function that takes as a parameter an rvalue reference (and within that function the 'resource stealing' takes place).

[@kim4857-u7j]

Thanks

[@MikeShah]

Thank you!

[@dogdog5994]

I'd love to see more videos for WxWidgets, an in-depth series about WxWidgets, basically. An in-depth series about creating GUI win32 apps in C++ and C would be interesting as well. It's hard to find good videos about it on youtube. The message loop and the processing of messages is interesting. Modern WinForms and to a lesser degree WPF apps are wrappers around the win32 GUI which makes it relevant for learning those too.

[@MikeShah]

Noted! I have a few videos on wxWidgets. Will certainly be adding to this playlist

[@VoidloniXaarii]

Thanks a lot again. This did indeed make move semantics just a little bit less scary

[@MikeShah]

Cheers, you are most welcome!

[@dhanushs1802]

Very well explained as always. Thank you.

[@MikeShah]

Cheers thank you for the kind words

[@bernhardkneer5393]

Hi Mike, I like your Videos and was looking for something about perfect forwarding. Do you have such a video already? I‘ve understood this is used to avoid unnecessary copy constructor calls when Objects are being initialized and it also works for rvalues but I would like to understand the idea behind this a little better. Thanks and keep on going Bernhard

[@MikeShah]

Cheers! Perfect Forwarding is on the todo list for this series :)

[@dadlord689]

If I'm understanding it correctly - move is stack specific thing (deals with functions inner scope parameters recopying problem).

[@MikeShah]

Not necessarily stack specific, but could in fact 'steal' the ownership of an inner scope to some other outer scope object.

[@dadlord689]

@@MikeShah In the scope of execution flow as I get it. I have figured out that variables (stack allocated bits of data) - can be cast to rvalue and this will allow to assign their value to something else on this stack (a variable of the same type or a field of a struct). And by struct I mean a complicated data type yet allocated on stack (not heap). But once the data is written within a field of an object that is allocated on heap - you won't be able to move it anywhere. And so in my opinion this concept of move is just badly implement in the language, causing frustration. So technically I think it would be fair to say that move is possible only within stack mamory (as any function is called on stack allocating it's parameters on it, yet allowing to intake an rvalue of something from the outer, relative to this function, scope {this thing} ).

[@dadlord689]

As a representative of the pure frustration I have concluded the next: I believe that move operation is possible within CPU cache where anything from heap should be copied into (from RAM) in order to be rad or modified. And after that - result will be copied back to RAM (if modification occured). And so I guess that move operation is happening within CPU cache. And so I see the ram as a grid of bits. Only grid owns values in it's cells, so there is no spoon, Neo (there is no fields ownership concept in hardware). But it reminds me ECS where entity is just referencing (own) bunch of components while represents just an integer identifier. And so move should prevent non needed copy of an object that haven't left CPU cache stack yet. Anyway it looking to be a feature that will take time to realize.

[@djsixottawa]

Thanks for the crystal clear explanation! :)

[@MikeShah]

Cheers!

[@bufet88]

Mike, does modern C++ take care of the original object from which we have moved the data? If not, could there be a chance of UB if we try accessing it or is it considered safe?

[@MikeShah]

Object will be destroyed when it goes out of scope (if stack allocated) or otherwise when we delete it explicitly (if heap allocated). Otherwise, indeed since ownership has transferred, the object (or parts of it) may be in a sort of 'nullptr state'. That said, nothing prevents us from calling an 'initialize()' function that populates the object again with new data that it otherwise owns. So it really just depends on how you access it and what happens.

[@herrdingenz6295]

you forgot to mention one very important thing ... std::move doesn't always move .. sometimes it is forced to make a copy, like here: void some_function(const DataType& some_data) { auto temp = std::move(some_data); } this will actually copy some_data instead of moving it, even though it was given to the function by const reference ... and exactly there is the problem: you can't std::move const objects - that will always result in a copy

[@MikeShah]

Cheers--another good piece of information!

[@_ndot]

Hi, first of all thanks for the tutorials, been learning a lot. Regarding the move, I also thought this did some switcheroo with pointers but it seems its not always the case at least for std::string. After looking at the standard library and getting my eyes crossed, it seems a lot of the times the memory is just copied, and the first byte of the old memory is zeroed out. e.g. int main() { std::string s1 = "hello"; char* s_p = s1.data(); // Pointer to data std::cout

[@MikeShah]

I did a quick look, and it looks like it's doing the move. A pointer (underlying data) is only 8 bytes, so you're seeing the first byte swapped. It just so happens that the address is zero in that example it appears. Underlying data (e.g. size) looks likely also being updated, or otherwise size may not get updated until a write (e.g. copy on write).

[@donaldslowik5009]

You have to update s_p after the move from, and look at pointers, not their addresses: std::string s1 = "hello"; char* s_p = s1.data(); // Pointer to data std::cout

[@gregorypeck6791]

very very good explaination ! 👍

[@MikeShah]

Cheers!

[@oscarmvl]

Very clear example! Thank you.

[@MikeShah]

Cheers, thank you for the kind words!

[@Elmano-h3r]

clear language good clarification ty sir mike

[@MikeShah]

Cheers!

[@k0185123]

Nice!!!! But I don't really understand how that static_cast(mystring) works. Does it mean the type of "mystring" is converted into the rvalue reference std::string&&? If so, why does "myString" become empty after the assignment?

[@MikeShah]

static_cast(myVariable) is effectively the same as std::move, but std::move documents exactly what you want do (to return an rvalue reference). myString becomes empty because we are 'stealling the resource' away when we assign it elsewhere. This is a way of programming where you only have one unique owner of data.

[@k0185123]

@@MikeShah I see! Thank you for the clarification :)

[@crazymemes4080]

Mike does this move only work's for strings? Can i move a vector of number to another vector?

[@MikeShah]

Move works for vectors and many other containers. Only if the container says non-moveable (i.e. move operator has been =delete()) is it not possible :)

[@venturaromero5908]

Thanks a lot Mike for this series. Related to the std::move, i tried to extend the example by printing both variables' addresses. How come that the addresses of myString and newValue don't change? std::string myStr = "hey fella"; std::string otherStr; std::cout

[@MikeShah]

I didn't run the example, but if the other object is empty, effectively we have just performed a swap of the objects during the move. perhaps the compiler found that optimal. Will need to run in godbolt to see.

[@aslichg]

Hallo, thanks for nice tutorials first of all. I am learning a lot. I tried this move semantics for int variables and it did not work as it is. First initialized variable did not loose its value. So this operation works well for string only?

[@MikeShah]

For primitive types I would not expect anything to change -- meaning there's no data on the heap. If you allocate a single pointer to an integer however, the pointer should move. 🙂

[@DhananjaySingh-po2uc]

I believe it works only for the object which implements overloaded move assignment operator. So it works for string,vector types but not for primitive types

[@__hannibaal__]

Hello ; It s just hint : If we have two object OBJ1 { heavy resource }; and OBJ2 {}; Instead to move these resource so why not just move the named object OBJ1 OBJ2; or move only reference address ;…. ???

[@MikeShah]

std::move is effectively doing that move of resources.

[@__hannibaal__]

@@MikeShah Yes 👍; i still digging deep and deep in structure of C++; and how it made thing so beautiful. Thanks mike for your help.

[@MikeShah]

@@__hannibaal__ Cheers!

[@my4127]

5:50

[@PramodKumarTrueFriend]

very nice

[@MikeShah]

Cheers!

[@Luckygangff]

hi mike i'm big fan of you l like your videos i used this function fun() two different ways below #include void fun(std::string &&dummy){ dummy+="shaik"; } int main() { std::string s="azeem"; fun(std::move(s)); std::cout

[@MikeShah]

I think this is working as expected, Consider the string 's' that you are passing in both cases is appending a string literal to the string. 'dummy' passed by reference in the second case makes sense that this is doing an append. In the first case, += is merely allocating space for the additional 'shaik' and appending it to the storage, there's no real change in ownership here.

[@Luckygangff]

@@MikeShah thanks for the replay can you please make a video on semaphores

[@MikeShah]

​@@Luckygangffcheers! Have you seen my other concurrency videos? Perhaps I can add for semaphores, latches, etc.

[@Luckygangff]

@@MikeShah I have seen those videos, and suggested to so many friends. Waiting for new videos

[@MikeShah]

@@Luckygangff cheers!

[@guilherme5094]

👍!