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(*t his);
}
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(*t his);
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.