c++ - Is it possible to std::move local stack variables? -

please consider following code:

struct mystruct {     int iinteger;     string strstring; };  void myfunc(vector<mystruct>& vecstructs) {     mystruct newstruct = { 8, "hello" };     vecstructs.push_back(std::move(newstruct)); }  int main() {     vector<mystruct> vecstructs;     myfunc(vecstructs); } 

why work?

at moment when myfunc called, return address should placed on stack of current thread. create newstruct object gets created, should placed on stack well. std::move, tell compiler, not plan use newstruct reference anymore. can steal memory. (the push_back function 1 move semantics.)

but when function returns , newstruct falls out of scope. if compiler not remove memory, occupied existing structure stack, has @ least remove stored return address.

this lead fragmented stack , future allocations overwrite "moved" memory.

can explain me, please?

---

edit: first of all: thank answers. have learned, still cannot understand, why following not work expect work:

struct mystruct {     int iinteger;     string strstring;     string strstring2; };  void myfunc(vector<mystruct>& vecstructs) {     mystruct onewstruct = { 8, "hello", "definetly more 16 characters" };     vecstructs.push_back(std::move(onewstruct));      // @ point, onewstruct.string2 should "", because memory stolen.     // when explicitly create move-constructor in form     // stated yakk, case. }  void main() {     vector<mystruct> vecstructs;     myfunc(vecstructs); } 

first, std::move not move, , std::forward not forward.

std::move cast rvalue reference. convention, rvalue references treated "references permitted move data out of, caller promises don't need data anymore".

on other side of fence, rvalue references implicitly bind return value of std::move (and forward), temporary objects, in cases when returning local function, , when using member of temporary or moved-from object.

what happens within function taking rvalue reference not magic. cannot claim storage directly within object in question. can, however, tear out guts; has permission (by convention) mess arguments internal state if can operation faster way.

now, c++ automatically write move constructors you.

struct mystruct {   int iinteger;   string strstring; }; 

in case, write looks this:

mystruct::mystruct( mystruct&& other ) noexcept(true) :   iinteger( std::move(other.iinteger) ),   strstring( std::move(other.strstring) ) {} 

ie, element-wise move construct.

when move integer, nothing interesting happens. there isn't benefit messing source integer's state.

when move std::string, efficiencies. c++ standard describes happens when move 1 std::string another. basically, if source std::string using heap, heap storage transferred destination std::string.

this general pattern of c++ containers; when move them, steal "heap allocated" storage of source container , reuse in destination.

note source std::string remains std::string, 1 has "guts torn out". container things left empty, don't recall if std::string makes guarantee (it might not due sbo), , isn't important right now.

in short, when move something, memory not "reused", memory owns can reused.

in case, mystruct has std::string can use heap allocated memory. heap allocated memory can moved mystruct stored in std::vector.

going bit further down rabbit hole, "hello" short sbo occurs (small buffer optimization), , std::string doesn't use heap @ all. particular case, there may next no performance improvement due moveing.