Home Dashboard Directory Help
Search

POD struct global object initialization uses constructor by paercebal


Status: 

Closed
 as By Design Help for as By Design


1
0
Sign in
to vote
Type: Bug
ID: 564844
Opened: 6/2/2010 2:28:35 PM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

Hi all,

The bug was first described here : http://stackoverflow.com/questions/2960307/

I declare a global variable, myArrayOfPod, which is an array of a pod struct MyPod, using an initializer list initializer list. I then expect the structure to be initialized at compile time.

Still, the code below compare an array of POD struct with an array of void *, and shows that, before the DEBUG execution of main, the array of POD is NULL-ed, whereas the array of void * is correctly initialized.

In RELEASE, both are correctly initialized.

As every value is constant and known at compile time, and as the struct is a POD, I expect the array of POD to be initialized statically.

The same code was tested on gcc 4.4.3, where it behaves as expected (both arrays are initialized correctly).

Details
Sign in to post a comment.
Posted by Microsoft on 6/18/2010 at 4:50 PM
Hi -

Per the standard (this is in n3092 3.6.2/3):
"An implementation is permitted to perform the initialization of a non-local variable with static storage duration as a static initialization even if such initialization is not required to be done statically"

So even though oSomeGlobalObject is a dynamic initialization, the compiler is permitted to turn it into a static initialization (whether it does or not is implementation-defined).

n3092 3.6.2/2:

"Other non-local variables with static storage duration have ordered initialization. Variables
with ordered initialization defined within a single translation unit shall be initialized in the order of their definitions in the translation unit."

So, the order the variables are defined matters - if you declare oSomeGlobalObject AFTER your two arrays, then when the constructor runs, those two arrays will have the correct value. This only works within a single translation unit, of course.

The reason your codegen is different under debug and release is that you are engaging different optimization options in the compiler (/Od versus /Ox) which are changing the generated code and producing different (but conforming) results.

Based on this analysis, it does not appear this is a bug, and so I am resolving this issue as By-Design. Nevertheless, thanks for submitting this!

Andy Rich,
Visual C++ QA
Posted by Microsoft on 6/3/2010 at 12:41 AM
Thanks for your feedback. We were able to reproduce the issue you are seeing. We are routing 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.
Posted by Microsoft on 6/2/2010 at 5:04 PM
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.