[C++] Copy Elision failure in certain conditions

[C++] Copy Elision failure in certain conditions by Benjamin Lindley

Closed

as Deferred Help for as Deferred

Type:	Bug
ID:	775876
Opened:	1/5/2013 9:26:15 AM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

Copy elision does not take place under certain conditions where it is a perfectly valid optimization step. I understand of course that copy elision is not a requirement by the standard, but I think we would all agree that it is a huge boon. And since the Visual Studio C++ compiler obviously implements it, I have to assume that it is a bug if, under certain qualifying conditions, it does not occur.

Details (expand)

Visual Studio 2012

struct Noisy
{
    data_type data;
    Noisy(data_type d) :data(std::move(d))
    {
        std::cout << "construct\n";
    }
    Noisy(const Noisy& n) :data(n.data)
    {
        std::cout << "copy\n";
    }
    ~Noisy()
    {
        std::cout << "destroy\n";
    }
};

void Foo(Noisy n)
{
    std::cout << "Foo\n";
}

int main()
{
    Foo(Noisy(data_type()));
}

The previous code, compiled with Maximize Speed optimization, produces one of two outputs. Either copy elision takes place, and you get:

construct
Foo
destroy

Or it doesn't, and you get:

construct
copy
Foo
destroy
destroy

My tests indicate that copy elision does not occur if you replace 'data_type' with any type that has:

1) a user defined copy constructor and
2) a user defined destructor

For all other types, as far as I tested, copy elision occurs.

English

Windows 7 SP1

English

Copy elision does not occur if 'data_type' has:

1) a user defined copy constructor and
2) a user defined destructor

This includes the most useful standard library types, like std::string and std::vector<whatever>.

To be clear, it is the Noisy object copy that doesn't elide, not the 'data_type' copy. As copy constructors are silent for most types, I have no way of directly testing if copy elision occurs for those types.

Copy elision should occur irrespective of what 'data_type' is.

File Name	Submitted By	Submitted On	File Size
CopyElisionFailure.zip	Benjamin Lindley	1/11/2013	427 KB

Posted by Microsoft on 1/14/2013 at 1:59 AM

@Benjamin, thanks for your response, we have received your zip file. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
@UnitUniverse, thanks for your response.

Posted by Benjamin Lindley on 1/11/2013 at 3:38 PM

@UnitUniverse:
I understand that it's the coder's responsibility to make sure his classes function with or without copy elision. The issue here is not correctness. The behavior is standards conformant in this case. The issue is efficiency. An optimization(copy elision) is being applied under one condition, and then not being applied in another condition, even though that condition is not one that should prevent the optimization.

Posted by Benjamin Lindley on 1/11/2013 at 3:32 PM

I believe a zip file containing the project has been attached. I may have added it twice by mistake.

Posted by UnitUniverse on 1/11/2013 at 11:59 AM

@Ben
I think this kind of behaviour of the compiler is in design. The C++ standard allows such short-circuit optimization when an object is as the none-reference argument of a function or return-value from a function, although such optimization may have the risk of the logic-changing. It is the coder's responsibility to adjust one's code to let it be adapted for either with or without such optimization.

Posted by UnitUniverse on 1/11/2013 at 11:57 AM

@Ben
I think this kind of behaviour of the compiler is in design. The C++ standard allows such short-circuit optimization when an object is as the none-reference argument of a function or return-value from a function, although such optimization may have the risk of the logic-changing. It is the coder's response to adjust one's code to let it adapted for either with or without such optimization.

Posted by Microsoft on 1/10/2013 at 9:46 PM

Hi Benjamin, we want to remind you we need a demo project. Please reply to us as soon as possible. Thanks.

Posted by Microsoft on 1/10/2013 at 1:54 AM

Thank you for submitting feedback on Visual Studio and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting a demo project. We look forward to hearing from you with this information.

Posted by Microsoft on 1/5/2013 at 9:51 AM

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)