global object(s) construction

[ma740988]

When constructing - in this case static objects I've been advised to
use a 'manager' class. The desired order of construction per the
'sample/test' source below:

1. ic_msg
2. rec
3. rec_win_impl
4. main_win_impl

So now consider:

// msg_impl.h
#ifndef MSG_IMPL_H
#define MSG_IMPL_H

# include <iostream>
# include "rec.h"

extern class rec m_rec;

struct ic_msg {
void execute() {
//m_rec.update(*this);
}
ic_msg() {
std::cout << " ic_msg constructed " << std::endl;
}
};
#endif

// rec.h
#ifndef REC_H
#define REC_H

# include <iostream>
# include "msg_impl.h"

class rec {
friend struct ic_msg;
ic_msg m_msg;

void update(ic_msg& msg)
{
m_msg = msg;
}
public:
rec() {
std::cout << " rec constructed " << std::endl;
}
~rec() {}
void do_some_special_thing()
{
m_msg.execute(); // this is really called polymorphically but
// done/show for demonstration
}
};

#endif

//rec_win_impl.h
#ifndef REC_WIN_IMPL_H
#define REC_WIN_IMPL_H

# include <iostream>
# include "rec.h"

rec m_rec;
class rec_win_impl {
//rec *m_rec; // dynamic / 'old' approach
public:
rec_win_impl() {
// m_rec = new rec(); // dynamic / 'old' approach
std::cout << " rec_win_impl constructed " << std::endl;
}
~rec_win_impl() {}
};

#endif


// main_win_impl.h
#ifndef MAIN_WIN_IMPL_H
#define MAIN_WIN_IMPL_H

# include <iostream>
# include "rec_win_impl.h"

rec_win_impl m_rec_impl;

class main_win_impl {
// rec_win_impl *m_rec_impl; // dynamic / 'old' approach
public:
main_win_impl() {
// m_rec_impl = new rec_win_impl(); // dynamic / 'old' approach
std::cout << " main_win_impl constructed " << std::endl;
}
void test() {
}
~main_win_impl() {}
};

#endif

// now we're ready
# include "main_win_impl.h"
main_win_impl m_main_win_impl;

int main()
{
m_main_win_impl.test();
}

For starters, the m_rec object is declared as extern within msg_impl.h,
yet the compiler (.NET) complains that m_rec (commented out line -
below) is undefined.

// m_rec.update(*this);

The prime solution - assuming I understood correctly - is a
manager class. Source (helps me visualize better ) sample on such a
class would be greatly appreaciated.

The prime objective is to get a feel for/have a globally accessible
m_rec object that I could access - in this case - in msg_impl.