By static and global objects, I presume you mean objects with static lifetime defined at namespace scope. When such objects are defined with local scope, the rules are slightly different.

Formally, C++ initializes such variables in three phases: 1. Zero initialization 2. Static initialization 3. Dynamic initialization The language also distinguishes between variables which require dynamic initialization, and those which require static initialization: all static objects (objects with static lifetime) are first zero initialized, then objects with static initialization are initialized, and then dynamic initialization occurs.

As a simple first approximation, dynamic initialization means that some code must be executed; typically, static initialization doesn't. Thus:

extern int f();

int g1 = 42;    //  static initialization
int g2 = f();   //  dynamic initialization

Another approximization would be that static initialization is what C supports (for variables with static lifetime), dynamic everything else.

How the compiler does this depends, of course, on the initialization, but on disk based systems, where the executable is loaded into memory from disk, the values for static initialization are part of the image on disk, and loaded directly by the system from the disk. On a classical Unix system, global variables would be divided into three "segments":

I suspect that a lot of modern systems still use something similar.

EDIT:

One additional remark: the above refers to C++03. For existing programs, C++11 probably doesn't change anything, but it does add constexpr (which means that some user defined functions can still be static initialization) and thread local variables, which opens up a whole new can of worms.

Yes, all members of a are guaranteed to be initialised to 0.

From section 3.5.7 of the C89 standard

If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant.

Because that's the way it is, according to the C Standard. The reason for that is efficiency:

• static variables are initialized at compile-time, since their address is known and fixed. Initializing them to 0 does not incur a runtime cost.

• automatic variables can have different addresses for different calls and would have to be initialized at runtime each time the function is called, incurring a runtime cost that may not be needed. If you do need that initialization, then request it.

1. Straightforward answer

If the class is assignable/copy constructible you can just write

QFile file; //QFile class

int main()
{
    file = QFile("C:\\example");
}

2. Use indirection

If not, you'll have to resort to other options:

QFile* file = 0;

int main()
{
    file = new QFile("C:\\example");

    //
    delete file;
}

Or use boost::optional<QFile>, std::shared_ptr<QFile>, boost::scoped_ptr<QFile> etc.

3. Use singleton-related patterns:

Due to the Static Initialization Fiasco you could want to write such a function:

static QFile& getFile()
{ 
    static QFile s_file("C:\\example"); // initialized once due to being static
    return s_file;
}

C++11 made such a function-local static initialization thread safe as well (quoting the C++0x draft n3242, §6.7:)

Using a plain struct or class is, indeed, possible:

class Test { // or use struct without explicit public accessibility
public:
    int val;
};

Test  test1 = { 5 };

You:

• cannot do any fancy construction work using this plain layout and
• cannot have any member requiring construction.

Otherwise, you do not need worry about new or malloc if you program as you did in your example: test2 is cheaply allocated on the stack even though a constructor is called.

Just as a side note: consider using initializer lists when you do use constructors:

class Test {
  int  m_val;
public:
  Test(int  val) : m_val(val) {}
};

Main problem with global variables in C++ that compilers don't guarantee initialization order. Let's you have 2 global variables with constructors:

global_A g_a;
...
global_B g_b;

...

global_A::global_A()
{
    this->test = 5; // test is int
}

...

global_B::global_B()
{
    printf( "%d", g_a.test );
}

If initialization order of g_a and g_b is undefined, then sometimes you can get situation when constructor of g_b would be called before g_a and variable g_a.test would be undefined. The worst thing - sometimes it works well.

Note, if global variables in same source file then you may be sure that order will be same as global variables are defined. But using global variables with dependencies is bad practice because other people who will work with this code may not know about dependency between global variables and got troubles if move one of global variable to other file.

I see two problems with this, one a legality problem and one a usability problem.

The first problem is alignment: MyObject::s_pMyPlaceholder is not guaranteed to be suitably aligned to hold a MyObject.

The second problem is that you have restricted yourself to a single object of type MyObject. Create a second and you have overwritten the first with no warning.

I would suggest using boost::optional to delay initialisation of objects.