How to construct the global objects in a DLL module before the main() function is called in the host program?

Question

First I'll show my questions and then I'll provide more background details:

My Questions

1. Is it a good idea to define global objects in a DLL module?
2. Anyway, how should I ensure the global objects in the DLL module are constructed before the main() function is called in the host program?

Background

I'm wokring in a Visual C++ project on Windows platform(but at the same time we need to guarantee the cross-platform capability of our source code to support Linux ).

One of my colleagues was asked to design and implement some stand-alone DLL modules which could be shared by the other projects. He planned to develop two DLLs with different purposes:

1. DLL#1 - An interface manager module, which looks like a simplified COM. This DLL would contain a C++ class which manages all the factories of the utility classes.
2. DLL#2 - A container of all the utility classes and their corresponding factory classes.

His considerations of such a design include:

1. COM is not cross-platform-able. Besides, COM is a bit too complicated for our project circumstances so he designed this Simplified COM library.
2. He doesn't put everything in one DLL because he believes this Simplified COM library is quite independent and shouldn't be mixed with such utility classes as "XML parser". And I agree to this point.
3. All the utility classes have their corresponding factory classes. My colleague defines a global object for each factory class, in the .cpp files in DLL#2, and writes some tricky code to let them register to the Simplified COM library. His intention is: The global objects should be constructed before the main() function in the host program is called, and during the constructions they are registered to the Simplified COM so that the host program could create instances of the utility classes as soon as it comes into the main(). This behavior is quite similar to COM. I agree to this point but my questions also arise as I mentioned in the "My Questions" section.

In fact, with some real test, we found these global objects could not be constructed as intented, which, sadly, breaks his heart ;-). But I think his design still looks good so we want to figure out some way to make it work. We'd prefer to use these DLLs in this way: The DLLs are deployed in the developers' computer with libs and includes. Then in a concrete VC++ project they are incorporated at the link-time. Right now we don't have an compile or link errors but just these global objects in DLL #2 are not created as desired.

Answer 1

Can't you use the DLL's DllMain() function to initialize everything? Just check for DLL_PROCESS_ATTACH , which will let you know if the DLL is just being loaded right now. Similarly, you can use DLL_PROCESS_DETACH to perform any cleanup.

If you're keeping things open for Linux, you can also use GCC's __attribute__((constructor)) .

As for your questions:

1. It's about a good idea as using globals in an executable. Whether it's a "good" idea or not is completely subjective. I personally avoid globals as much as possible, as it simplifies things (less spaghetti code; passing references/objects as parameters makes dependencies clear; less threading issues; etc.). I can't give a firm "yes" or "no" because I don't fully understand your use case. An example would help.
2. I don't understand why they need to be created before the main() function. If you can guarantee they're created in DllMain() , which will be called before any other function in the DLL (and the user doesn't call it; the OS does), do you still really need it to be before main() ? I'd be surprised.