What is the problem with the rvalue reference of c++14?

Now there are several structures:

typedef struct _INFO_HEAD{U_INT src_ip;u_int dest_ip;u_int src_port; u_int Dest_port;} info_head;typedef struct _pkt_info{u_long sec;u_long u_sec;u_int pkt_size;u_int pld_size;} pkt_info;typedef struct _PKT {Info_head head;pkt_info info;} Pkt

Although these structures are made up of basic types and do not involve dynamic memory management, the volume is indeed a bit. Where Info_head is 16 bytes and Pkt_info is 24 bytes, then a PKT is 40 bytes. This is just the case on a 32-bit machine.

Then we came across a class that uses the list container to store variables of multiple PKT types.

Class Pkt_list{public:static list< pkt > head_to_pkt;public:static int append (const info_head &, const PKT_INFO &);};

Let's implement the Append () function.

int pkt_list::append (const info_head &head, const pkt_info &info) {PKT Tmp;tmp.head = Head;tmp.info = info;head_to _pkt.push_back (TMP); return 1;}

　　Since PKT only contains basic types, it is good to use it directly, without new, and without worrying about memory management.

Here we see the first question, in order to combine a set of variables of type Info_head and Pkt_info into a variant of the PKT type, you must re-assemble a variant of the PKT type. That is, the memory already has 16B Info_head and 24B Pkt_info, but also use 40B to store and the previous pair of variable values exactly the same type of PKT variable. Although there is a suspicion of wasting memory, but this is not to be avoided, because we can not guarantee that the previous two 16B and 24B things together. So it's not really a waste.

But then another problem is that when you move the PKT type variable into the list<pkt>, the memory is copied once again. Because TMP disappears after the APPEND function ends, it's natural to want to keep the variable in the List<pkt> head_to_pkt, and then copy it.

So, we've used 120B of memory to save the same piece of data. This is indeed a very wasteful move. But there was nothing we could do before c++14.

The concept of rvalue reference, also called move semantics, is proposed in c++14. Concrete how a meaning does not say, directly say the effect, that is can save 40B of overhead. But how did this happen? It is simple to simply move the second 40B directly into the container and not copy it again. So, List<t>::p ush_back (t&); it should be another more efficient version, that is List<t>::p ush_back (t&&);. In general, STL has a rewrite.

Next, in order to use the second version of the Push_back function overload, we must write in the parameter list as the right value of the nameless variable, but if a register variable tmp has been used, then the cost of the 40B is no matter how to save, so TMP has a name, It's not the right value anymore. To get a nameless variable of the PKT type, it is necessary to write a constructor again for PKT. After the whole change, it's probably like this.

Class Pkt{public:pkt () {}pkt (const info_head &h, const pkt_info i): Head (h), info (i) {}info_head head;pkt_info info;};.. . int pkt_list::append (const info_head &head, const pkt_info &info) {head_to_pkt.push_back (PKT (head, info));//w ITH move semantics version being used, it works.  return 1;}

Ok. summed up so much.

What is the problem with the rvalue reference of c++14?