Home Dashboard Directory Help
Search

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


Status: 

Closed
 as Deferred Help for as Deferred


2
0
Sign in
to vote
Type: Bug
ID: 775876
Opened: 1/5/2013 9:26:15 AM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description

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
Sign in to post a comment.
Posted by Niels Dekker on 4/4/2014 at 2:57 PM
Reproduced on Visual C++ 2013 (Release configuration). Here's a somewhat simplified example, based on the description of Benjamin Lindley. It throws an exception ('throw 123456789') when the copy-constructor of Bar is called, indicating that no copy elision was applied.

struct Foo
{
    Foo() {}
    ~Foo() {}
    Foo(const Foo&) {}
};

class Bar
{
    Foo m_foo;
public:
    Bar(Foo arg) : m_foo(arg) {}
    Bar(const Bar& arg)
        :
        m_foo(arg.m_foo) { throw 123456789; }
};

void f(Bar) {}

int main()
{
    f(Bar(Foo()));
}

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)
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
CopyElisionFailure.zip 1/11/2013 427 KB