windows .dll vs. linux .so - global static objects

This is a discussion on windows .dll vs. linux .so - global static objects within the C++ Programming forums, part of the General Programming Boards category; Hi,
a singleton (static, global) object is used from the main app as well as from an dynamical loaded .so/.dll
...

windows .dll vs. linux .so - global static objects

a singleton (static, global) object is used from the main app as well as from an dynamical loaded .so/.dll

I observe the following differences in behavior under linux and windows:

under linux the object is created once, at the first call to the singletons instance function (i checked with debug output in the ctor of the class)

but under windows the object is created twice: one time when the main app calls instance() the first time and a second time when instance() is called from the dll for the first time. As you can imagine that behavior really sucks if you want to access consistent data stored in the singleton object from the main app as well as from the dll.

Is there any way to get the behavior under windows/dll exact like under linux/so?

especially since i see no real need for this class at all. the thing is that as soon as you start using dlls your singleton pointer won't work over library boundaries because each dll would reimplement the static pointer locally. to solve this you would have to provide a static overload of the getSingleton method in each class that derives from Singleton. what remains is that you have abstracted the storage of the singleton pointer in a hacky and ugly way (the static_cast would take away the uglyness but still the whole thing would be more of an OOP beautification than being really useful)

but I'm to silly to understand what exactly he means. could anyone translate his solution

to solve this you would have to provide a static overload of the getSingleton method in each class that derives from Singleton.

In DLL's in (C++) singletons are just of limited use. Because unlike libraries (I think he's talking about static ones), DLL's are not linked to the program. they rather are life-time linked (don't ask me about this, I don't understand it even in german). A singleton used by the main application and a DLL is going to be a seperate object in both modules.This can intricately be avoided by letting the main application pass the own instance of the singleton to the DLL. This is a special case of the mentioned scope problem (of singletons)

So it looks like my only chance is to pass a pointer to the singleton object to the dll. I still have no idea how to do that

Just don't use static storage for data you want to access over DLL/EXE boundaries, better use 'extern' storage.
This implies that you have to modify the implementation of the singleton pattern if you want to use it: E.g.
singleton.h:

windows .dll vs. linux .so - global static objects

Code:

Hi,
Thanks for the reply!
I have followed the approach as per your suggestion and have come up with few doubts. Please correct me if i am wrong in any step.
Find my sample code below:
sample.hpp:
class sample;
//extern sample* singleton_object;
sample* instance();
class sample{
public:
int i;
private:
//sample();
};
sample.cpp:
#include "sample.hpp"
sample* singleton_object = new sample;
sample* instance(){return singleton_object;}
Here are the doubts:
i> Can i pl know what is the intended use of extern in your suggestion?
Because even without using extern my code works fine.
ii> Also the constructor is not private in this approach. so, how the class can be made singleton?
Please help me out!
Awaiting for your reply..

Here are the doubts:
i> Can i pl know what is the intended use of extern in your suggestion?
Because even without using extern my code works fine.

It instructs the linker to resolve the symbol if it finds it in a compilation unit. If you use static linkage the compiler/linker will rather duplicate the storage (so you end up with the problem you observed).
The reason your code works w/o the extern keyword may be either because of that extern linkage is the default (I'm not sure about it) or because of that you haven't really compared the memory addresses of your "singleton" object from .exe and .dll context.

Originally Posted by lakshmi.ag

ii> Also the constructor is not private in this approach. so, how the class can be made singleton?

By not actively calling the ctor. If you find that not satisfactorily you could try to do some trick like making it private and call it explicitly maybe from main() which could be declared as friend.
Yes, thats not really the original singleton pattern, but to my knowledge there is no way in C++ to implement it w/o the described problems (There are others as well). I recommend to just not use it and rather control the object lifetime and construction/destruction like for any other entities.