Non static global object vs global pointer to dynamic object

Question

Got an unexplained behaviour with the following:

Case 1:

a.cpp compiled as a .dll library and used in main() of main.cpp

Bar b; 

//constr
Bar::Bar(){
  //... initialize members
}

//private library init
Bar::init(){ ...}

//public API init
bool lib_init(){
  b.init();
}

From what I understand, this approach may fail due to undefined initialization behavior of globals.

Case 2:

a.cpp compiled as a .dll library and used in main() of main.cpp

Bar* b; 

//constr
Bar::Bar(){
  //... initialize members
}

//private library init
Bar::init(){ ...}

//public API init
bool lib_init(){
  b = new Bar;
  b->init();
}

This time it works, when dynamic allocation is used.

Case 3 (most surprising)

a.cpp compiled as a .dll library and used in main() of main.cpp

static Bar& getBarObj()
{
  static Bar g_objBar;
  return g_objBar;
}

//constr
Bar::Bar(){
  //... initialize members
}

//private library init
Bar::init(){ ...}

//public API init
bool lib_init(){
  getBarObj().init();
}

As opposed to case 1, where Bar obj instantiation might have been undefined, in case 3 it is used "upon request". Yet, case 3 provides same behaviour as case 1.

And my question is ... can anyone explain what's going on here? Everything is built with VC2008 Release mode (have no option for Debug mode for this proj)

In Bar constr, I've got an initialization loop. One of its members is a fixed size array of type struct Foo, defined in "a.h". For instance, instead of iterating SIZE_OF_ARRAY = 8 times, the loop iterates like 50K times ... — BegemoD, Apr 30 '12 at 07:21
Please edit that into your question, _including the relevant code_ - nothing of your actual problem is described in that (already long) post. — Mat, Apr 30 '12 at 07:22

score 0 · Answer 1 · answered Apr 30 '12 at 06:56

0

Order of initialization of globals from different files (a case you definitely have) is undefined in C++. This means that if you depend on Bar b having been constructed during globals initialization in a different compilation unit, your program is undefined.

Why Case 3 is supposed to work, is because it forces you to use a function to refer to Bar b and this function guarantees that Bar b will have been constructed by the time this function returns.

If you tell us what exact undefined behavior you're getting, and provide the smallest amount of code to analyze, we may be able to help further.

P.S. Does your Bar constructor depend on another global having been constructed?

answered Apr 30 '12 at 06:56

Irfy

9,323
1
45
67

in a.h, except for Bar class definition, I've got a Foo struct. One of Bar's members is a fixed size array of Foo: – BegemoD Apr 30 '12 at 07:18
Could it be that `SIZE_OF_ARRAY` is a global that is not initialized by the time you reach `Bar` constructor? Only that could cause 50k iterations. Can you print the value of `SIZE_OF_ARRAY` before initializing `Bar` to make sure it is initialized? – Irfy May 03 '12 at 03:50

score 0 · Answer 2 · answered Apr 30 '12 at 07:24

Case 1 may fail since the construction of b is essentially left to the linking order (that is not controlled by the C++ spec: it is undefined behavior for C++, but the behavior can be defined by the linker!) In any case, once you call lib_init b is granted to be constructed being lib_init and b leaving in the same module.

Case 3 construct b at the time it is required and will destroy it at termination in construction reverse order with all the other static and global objects. This may give some problem with old compilers if Bar::Bar() calls in turn a foo_init() having a static Foo inside: you need Bar and Bar needs Foo but Bar is created before Foo and Foo destroyed before Bar that mat still needs it. This fact should anymore happen since 2003 spec. required destruction scheduling to happen after construction completion (so Foo ctor completes before Bar ctor and hence bar dtor will be called on termination before Foo dtor.

Case 2 is "ugly": works on cotruction like case 3 (creates on demand) butwith two problems:

The pointer should be static, just to avoid to create more than one object in case of multiple call to lib_init() and ...
Who will ever destroy Bar? The Os will clain the memory back at termination, but no dtor will be called.

Case 2 shold have probably better defined as

void lib_init()
{
    static std::unique_ptr<Bar> p(new Bar);
    p->init();
}

but this will make it like case 3.

Non static global object vs global pointer to dynamic object

Case 1:

Case 2:

Case 3 (most surprising)

2 Answers2