By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,952 Members | 1,424 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,952 IT Pros & Developers. It's quick & easy.

the initialization of the main program and its loading DLL

P: n/a
Dear All,

Now in my current developing project, I have defined a global object
in the main program . In dlls, there are also some static object whose
constructor will use the global object in the main program. But the
problem is always the initialization of the dll is prior to the main
program. How can I do if I wanna the main program be initialized
first?

Thank you very much!

Best,
Tony
Nov 12 '08 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Nov 12, 5:06*am, blackbiscuit <infozyzh...@gmail.comwrote:
Now in my current developing project, I have defined a global object
in the main program . In dlls, there are also some static object whose
constructor will use the global object in the main program. But the
problem is always the initialization of the dll is prior to the main
program. How can I do if I wanna the main program be initialized
first?
A standard portable solution for this problem is to have an explicit
initialisation (and often deinitialisation) function for your .dll
or .so. This function initialises the global state of the shared
library. Following this approach you don't depend on any platform
specific initialisation routines like DllMain or gcc constructor
functions.

Example:

// library.h
#include <memory>
#include <iosfwd>

struct Library
{
virtual ~Library() = 0;

virtual void foo() = 0;
virtual void bar() = 0;

// initialisation arguments
struct Args {
// arguments as needed, for example:
std::ostream* log;
};
// the initialisation routine / factory function
// only this functions needs to be exported
// (for .dll it should be __declspec(dllexport/import)
static std::auto_ptr<Libraryopen(Args const&);
};

// main application / library client
#include "library.h"
#include <iostream>

int main()
{
// open / initialise library
Library::Args lib_args = { &std::cout };
std::auto_ptr<Librarylib(Library::open(lib_args));
// use the library
lib->foo();
lib->bar();
// done with the library
// std::auto_ptr destructor calls Library::~Library
// which deinitialises the library
}

// library.cpp
#include <ostream>
#include "library.h"

namespace {

struct LibraryImpl : Library
{
Args args; // library global state

LibraryImpl(Args a) : args(a)
{
// do required initialisation here
*args.log << "Library has been initialised\n";
}

~LibraryImpl()
{
// do required deinitialisation here
*args.log << "Library has been deinitialised\n";
}

void foo() { *args.log << "Library::foo()\n"; }
void bar() { *args.log << "Library::bar()\n"; }
};

}

Library::~Library() {}

std::auto_ptr<LibraryLibrary::open(Args const& args)
{
return std::auto_ptr<Library>(new LibraryImpl(args));
}

--
Max

Nov 12 '08 #2

P: n/a
On Nov 12, 6:06 am, blackbiscuit <infozyzh...@gmail.comwrote:
Now in my current developing project, I have defined a global
object in the main program . In dlls, there are also some
static object whose constructor will use the global object in
the main program. But the problem is always the initialization
of the dll is prior to the main program. How can I do if I
wanna the main program be initialized first?
I'm not sure I understand. Are the DLL's being loaded
explicitly, or implicitly? (It's generally a good idea to avoid
DLL's except when necessary. For user written DLL's, this
really only occurs when the DLL's are loaded explicitly.)

The initializers in a DLL won't be called until the DLL is
loaded, so the simple answer is not to load it until after
you've entered main. If for some reason, explicit loading isn't
an option, or it must occur before entering main, then the
problem is basically the same as with static linking; some
variant of the singleton pattern is the usual solution.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Nov 12 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.