On 7/11/05, Andrey Melnikov <melnikov@simplexsoft.com> wrote:
David Abrahams wrote:
On a compiler supporting RVO and other kinds of copy elision, the "terrible" version could be just as efficient, or more so.
I can't imagine how a compiler can avoid calling a non-trivial copy constructor like in case of std::string. Don't forget that such a copy operation includes memory reallocation, which is much more expensive than just a memcpy() operation.
Modern compilers do. You can verify this with the attached test program that wraps std::string with "noisy" constructors, assignment op and destructor so you can see what is happening. With gcc 3.3.4 and no optimizations I get the following output: noisy_string::ctor: 0xfeffad90: forty-two noisy_string::dtor: 0xfeffad90: forty-two With MS VC++ 7.1 I get this output for any optimization levels I try: noisy_string::ctor: 0012FEA0: forty-two noisy_string::copy ctor: 0012FEC8: forty-two noisy_string::dtor: 0012FEA0: forty-two noisy_string::dtor: 0012FEC8: forty-two With MS VC++ 2005 Beta 2 I get the same output as above with no optimization, but at /O1 or /O2 I see NRVO kick in: noisy_string::ctor: 0012FF54: forty-two noisy_string::dtor: 0012FF54: forty-two With Sun C++ I get this: noisy_string::ctor: ffbee63c: forty-two noisy_string::copy ctor: ffbee6c0: forty-two noisy_string::dtor: ffbee63c: forty-two noisy_string::dtor: ffbee6c0: forty-two See what you get with your compiler. -- Caleb Epstein caleb dot epstein at gmail dot com