DLLka oraz EXE ktory ja laduje, to dwa oddzielne moduly. kazdy z nich ma wlasne przestrzenie w ktorych tworzone sa static'i i w dodatku - heh - sa oddzielnie budowane i kompilowane.. Stad dllka ma swoj static, i exe ma swoj wlasny static. Jezeli by tak nie bylo, jezeli static nalezalby do .exe - a Ty bys wzial DLLke i zaladowal ja do inego exeka, ktory z tym nie bylby skompilowany, to co by sie stalo? po zaladowaniu skad dll wytrzasnelaby sobie fizyczne wystapienie obiektu zdefiniowanego w tym .h?
To skoro juz, mam nazieje, wiadomo czemu - to rozwiazanie jest banalne. Musisz OKRESLIC ktore z nich ma RZĄDZIĆ i POSIADAĆ ten obiekt statyczny, a które z nich ma od niego go łaskawie dostawać.. nastepnie, musisz zadbac, aby implementacje CLOG dla lewej i prawej storny byly inne: lewa ma dostarczac i utrzymywac obiekt, prawa ma udawac ze to robi a tak naprawde ma pobierac go od lewej. To znaczy, ze musisz:
- dorobic ekstra eksport z dllki
- rozbic -jakos- klase na dwie blizniacze implementacje
- połatać wszystko razem aby nikt nic nie zawuażył
Innymi słowy, np.:
#ifndef JESTEM_DLL
class CLog;
CLog& _declspec(dllimport) provideLogger();
#endif
class CLog
{
...
#ifdef JESTEM_DLL
static CLog& GetInstance(){ static CLog ins; return ins; }
#else
static CLog& GetInstance(){ return provideLogger(); }
#endif
...
};
#ifdef JESTEM_DLL
CLog& _declspec(dllexport) provideLogger() {return CLog::GetInstance(); }
#endif
#define Log CLog::GetInstance() #///bez zmian
zamiast eksportowac funkcje "provideLogger" możesz wyciagnąć zmienna statyczna "static CLog ins" z poziomu lokalnego metody na poziom statycznego pola klasy lub globalny i potem samo tylko to pole eksportowac i wykorzystywac w analogiczny sposob (zamiast metody). Ale to w gruncie rzeczy na to samo wychodzi