   Calling functions from DLLs & accessing singletons
  I've got my client set up so that a user can drop a specially designed DLL file into the /Expansion/ directory, and the game will load it up and get the function address and all that good stuff.  That all works fine.However, I have a set of global variables that I've declared and instanciatd in the program (not the DLL) as such:class Global : public Singleton<Global>{public:Global() {};//  misc data members here}void main() {Global* G = new Global;//... continue to instanciate and set values to the Global Variables// eventually call the DLL function: Expansion_Foo()}I need to be able to access those globals from inside the DLL function.  However, when I try:void Expansion_Foo(){Global* G = Global::InstancePtr();}it comes back NULL, having never been instanciated.So, is what I'm trying to do possible?  How do I have to restructure in order to make it work?   
  What happens here is that your application code runs in your application space and the dll code runs in the dll space. That means you can't access your application's data from dll and vice-versa.I'm not sure, but i think you can pass your data as a parameter to the function in the dll.i think communication can happen between the application and dll, but you'd need to use COM to make it works (i'm not sure of that tough)Also, for the dll files in the /Expansion/ directory, i think you'd need a common interface to your dll (the same functions names in each dll that do different things) like expansion_init(), expansion_do_stuff_x(). Then it would be easy to call those functions from your application using any dll in the /Expansion/ directory. As for searching dlls in a certain directory, it's not automatically done, you'll have to use FindFirstFile(), FindNextFile(), LoadLibrary() and GetProcAddress() (all win32).hope that helps !   ;  You will have to have pointer vars local to the DLL and have some kind of Init routine  to pass the addresss to the globals across to the DLL code to be stashed.You then have to use them as pointers -- access the globals indirectly (instead of direct use like you could in the main program).  You might also think about restricting access to the globals via functions (in the main program) and make calls to those functions in the DLL.  You would have to pass pointers to those routines (callbacks) for use in the DLL in an Init routine.Eithet way you have to do some indirection......   ;  Yeah, about 5 mins after posting it hit me, duh, just pass a pointer.  Now, I can keep passing a poitner to the Global class here and there, but I'm trying to make it a bit cleaner.  But it seems the application space and dll space barrier has thwarted me again; the static pointer variable is NULL in dll space, even though it was instantiated in app space.  So that means that even though i pass Global* G to my DLL func, and it can use G just fine, when it in turn goes to make a call to Bar() [which is back in application space], its running it in dll space.  Which, of course, means that any references to Global::InstancePtr() in Bar() are now NULLed out.I'll get this figured out.  :)  It just might not be as clean as I'd like it.   ;  As for templated classes you need to export the template codeI dunno if that matters for class derived from templated classes as well, you need to test this.For more information lookup the MSDN on STL vector across dlls   ;  Thanks for the info.I ended up making it a not-so-singleton, where it just had a static pointer to itself and a Set function:class Global{    static Global* G;    void Set(Global* g) { G = g; }}At the beginning of any DLL-space function, I call Set:void Foo(Global* G) {    G->Set(G);}And continue on as normal.  It seems redundant, but in DLL-space, the static hasnt been set, so its still NULL by default.  Setting it to the appropriate value allows any further Global::G calls to be valid, whether its in App-space or DLL-space.So, its a little confusing, but works like a charm!;Just an idea,your dll contains code for some class/classes doesn't it ? So, when creating those classes, why not giving them the pointers they need, instead of having a global around. Statics etc are a bit bad with DLLs, I don't see a great difference between having Global *pGlobal or static Global *pGlobal as a member of the class.I don't want to start a debate over singletons etc ... there's been enough of discussions about them already. By experience I try to avoid singletons etc, especially after using extensively dlls. Cheers   ;  At this point I'm using a singleton-ish method of static pointers simply so I can avoid having to pass a Global* pointer to every function I would ever want to call.  void Foo(void) can still call Global::MyStaticPointer and get a handle on that set of globals.Question #1)New question, though, on this app-space/dll-space problem.  My APP.cpp is calling functions defined in the DLL.cpp, which in turn is calling functions in the APP.cpp.  In this scenario:HEADER.h----------------class Strings{  public:vector<string> MyStrings;};void Print(Strings* s);(HEADER.cpp contains the code for Print)APP.cpp----------------#include "HEADER.h"void main(){    Strings* S = new Strings;    S->MyStrings.push_back("One");    // Load DLLs, get a handle to DLL function Foo(Strings*)    (*Foo)(S);    S->Print();}DLL.cpp--------------------#include "HEADER.h"void Foo(Strings* s) {    s->Print();    s->MyStrings.clear();    s->MyStrings.push_back("Two");}--------------------Will this operate as expected, and print "One", "Two"?  Or will there be an error with the DLL modifying something that exists in the application's space?Question #2)Right now, my heirarchy isnt what I want it to be. I have:Common.h/cppMySQL.h/cpp includes Common.hGlobal.h includes MySQL.hQueries.h/cpp includes Globals.h - Expansion.h/cpp includes Globals.h(DLL)Foo.h/cpp includes Queries.h - main.cpp includes Queries.h & Expansion.hSo that means, to compile the DLL, I need to include the .h AND .cpp for Queries, MySQL, and Common. I'd rather not do that. So to get around that, I was going to wrap up Common+MySQL+Global+Queries into a library, then any DLL file (Foo.h) will only need to the headers and the library. So my question is, what happens to my Global class? (an alternate question would be: is there a better way to avoid having to include the CPPs in the DLL's project?)   ;  You seem to be confused about how DLLs work.As you have probably seen, a DLL must be linked, just like a standard executable. This poses a problem if you wish to call a function in the application that loads the DLL from the DLL itself, because the DLL can not be linked -- the linker has no object file that contains the definition of the application's function.Your solution to the problem is to link the function twice: once in the application and once in the DLL. Because code is constant (assuming you are not using self-modifying code) there is nothing inherently dangerous about this, it's just clumsy.The dangerous part comes from linking in data twice, which you have done with the static variable G. It appears from the declaration that it exists only once, but it exists both in the application and the DLL, and it must be maintained in both. Half of the solution to your problem is removing duplicated code and data from the DLL.Your DLL will still be able to access the application's code and data: when you load the DLL, the DLL's code and data is placed in the address space of the application. As a result, as long as you know the address of a symbol, you can access it.So, how do you know the address of an application symbol? You pass it in a pointer as a parameter to the DLL function. If you have many functions that you want to expose to the DLL, a simple solution is to create an interface class that contains only pure virtual member functions, then create a class that derives from the interface class, but implements the functions. Then, pass a pointer to this interface class to your DLL function.an example:-----app.h-----struct IApp{  virtual void foo() = 0;  virtual int *bar() = 0;  virtual int baz() = 0;};-----app.cpp-----#include "app.h"// some static app functionsstatic int flubber = 0;static void foo() { printf( "foo!" ); }static int *bar()  { return &flubber; }static int baz()  { return ++flubber; }struct AppImp : IApp{  virtual void foo() { ::foo(); }  virtual int *bar()  { return ::bar(); }  virtual int baz()  { return ::baz(); }};int main(){  AppImp ai;  void (*pbaz)(IApp* app);  // load the DLL, get the address of dll function baz, put it in pbaz...  (*pbaz)(&ai;  return 0;}-----dll.cpp-----#include "app.h"// export baz in your .def filevoid baz( IApp* app ){  int* app_flubber = app->bar();  *app_flubber = 100;  app->foo();  for (int i = 0; i < 10; i++)    printf( "%d ", app->baz() );}note that the DLL is able to modify application data (flubber) just fine.   