Predictional C ++ item6-7 temporary variables

Connection of temporary variables ~~

String findaddr (list <employee> EMPs/* input non-reference parameter */,

String name/* same as above */) {for (list <employee>: iterator I = EMPs. Begin (); I! = EMPs. End (); // It is recommended that you change this to the storage end () location to improve performance, but this should be considered comprehensively !, The following describes in detail the auto-increment after I ++/* will generate a temporary object */) {If (* I = Name) // wipe! This is too implicit... Temporary Variable caused by implicit conversion! {Return I-> ADDR;} return "; // a temporary variable will also be generated}

1. Use const reference instead of passing values;
2. If possible, use pre-auto-increment as much as possible (post-incrementing must be used in some cases );
3. The displayed constructor is used;
4. Prefer precomputing values that won't change, instead of recreating objects unnecessarily, which is the original statement in the book, but I personally think that in this case, you need to carefully choose: if you are sure that you will not perform any operations on the container that will cause the iterator to become invalid, there is no problem with this operation. However, if any operation causes the iterator to become invalid, this so-called efficiency improvement will become a bug... To sum up, we still don't need to use it...

The Connection check is over. The next question is:

string FindAddr( const list<Employee>& emps,                  const string&         name ){  list<Employee>::const_iterator end( emps.end() );  for( list<Employee>::const_iterator i = emps.begin();       i != end;       ++i )  {    if( i->name == name )    {      return i->addr;    }  }  return "";}

Or how can I use a general algorithm to improve this slightly improved version?

This function is actually a search task, sequential traversal, and find can do better ~ So, use find to replace the loop search to get better results ~

When will the compiler optimize the post auto-increment operator? The compiler will optimize the built-in types, but the compiler will not automatically optimize the class types unless: there is a way you can deliberately let the compiler see the relationship between pre-and postincrement for a class type: implement the canonical form of postincrement, which CILS preincrement, and declare it
InlineSo that the compiler can see your SS the function-call boundary (if it respects
InlineDirective) and detect the unused temporary object. implement the post-operator by yourself and declare it as inline, so that the compiler can see it (but whether it is determined by the inline or not, You know). The old invalidation problem is: any insert and push operations may invalidate the iterator (the container may not have enough space, and the application space is applied for and copied ); erase, pop_front, and pop_back will invalidate all iterators pointing to the deleted element. For vector containers, element iterators pointing to the deleted vertex will usually also become invalid. For deque containers, if the deletion does not contain the first or last element, all iterators related to the deque container will become invalid. Resize may invalidate the iterator, resize on vector and deque will invalidate all iterators; assign values and assign will invalidate all iterators in the left operand container;