A reasonable response, although the problem with this is that it's impossible to manipulate persons without causing their values to be copied (which might not even be possible given the other members of the type - which might not even be under the author's control, e.g. 3rd party libs). Additionally without extra complexity, simple pointer swapping tasks like moving a person between list suddenly starts to involve memory allocation, etc.
Right, but the same trade-offs apply to C; C++ is actually superior here: if something shouldn't be copied, you can enforce that in C++, but not in C.
The author was arguing that writing in C++/STL meant your code was necessarily less efficient than C; that just seems incorrect.
Edit: If you're referring to copying the person values when they're returned from the list: a reference is returned; the compiler will optimize that "pointer" away. Most C++ compilers can even do this when the value itself is returned and avoid the copy. My rule with C++ is that the compiler is stupid, but never where you expect. You need to optimize based on a profiler.
std::list<T>::splice() lets you move elements between lists without copies or allocations.
Before C++11, it was a problem that inserting an element into a std::list required a copy (that's the only place though - once in the list there are no more copies). C++11 adds move semantics and also std::list<T>::emplace(), which eliminate the need to copy.
Actually in this particular case that "copy" is allowed to be elided even in C++98, as the copy constructor of person produces no side effects. It would be hard to notice if the optimizer is that smart or not either way though, since it will be optimized by redundant load/store elimination even if it was initially generated without optimization.
