Presence of copy constructor breaks member class initialization - by Alex Vakulenko

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 499606 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 10/22/2009 1:49:36 PM
Access Restriction Public


Initializing native C++ class member in constructor's initializer list produces inconsistent behavior depending on presence/absence of copy constructors on child objects.
Sign in to post a comment.
Posted by Niels Dekker on 8/25/2014 at 8:12 AM
Good news: it appears that this compiler bug is finally fixed! As Kangyuan Niu (Microsoft) wrote in a comment at on August 21, 2014: 'Neither 499606 nor 484295 can be reproduced in Visual Studio "14" CTP 3'

I just tried to reproduce both Bug ID 499606 and 484295, after having installed VS "14" CTP 3 (compiler version 19.00.22013.1), but indeed, I failed, twice :-)

@Microsoft: If this bug is indeed fixed, as it seems, please mark it as "Fixed", instead of "Won't Fix".
Posted by ildjarn on 7/3/2014 at 3:56 PM
As of compiler version 18.00.30501 (for x64), v2 and v4 are uninitialized regardless of the presence of the user-defined copy constructor.
Posted by Ahmed Charles on 12/7/2013 at 8:23 PM
Actually, I take that back, I didn't compile in debug mode.
Posted by Ahmed Charles on 12/7/2013 at 8:21 PM
This bug seems to have been fixed, at least in:

Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
Posted by Alex Vakulenko on 9/17/2010 at 1:23 PM
Ok, I understand. But can you at least add a compiler warning so that we can catch problematic initializer usage like that in our code? That should help create much better code and prevent unexpected behavior from happening...
Posted by Microsoft on 4/14/2010 at 11:31 AM

Thank you for taking time to report this issue. While I can verify that this is indeed a bug in the compiler, making changes to the way our compiler understands POD-ness is a very dangerous change that can have unintended side-effects and break existing code - especially since, as you point out, this is a long-standing bug in the compiler. (We are aware this is a deviation of the standard, and it is something we hope to address in the future.)

In the provided example case, you can work around this issue by providing a default constructor for B.

Thanks again for taking the time to report this issue.

Andy Rich
Visual C++ Quality Assurance
Posted by Niels Dekker on 1/3/2010 at 1:23 PM
This looks like another example of the value-initialization bug originally reported by Pavel Kuznetsov (MetaCommunications) back in 2005:

Please, fix it!
Posted by Microsoft on 10/26/2009 at 2:28 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you
Posted by Microsoft on 10/25/2009 at 8:33 PM
Thank you for your feedback, We are currently reviewing the issue you have submitted.