   yet another DLL/class question
  Hi,I have a base class which has virtual members (but not pure virtual).  I want to have several DLLs which export classes that derive from this class.  Can I link to this class in my main program and then export the class from there so that all of my DLLs can use it?  There are also a number of other classes that are used by different DLLs, can I do the same?  Is that even the best way to do it?  Actually the way things are at the moment (this is in an existing project that I''ve started working on and I''m questioning whether it''s really being done the Right Way) (btw this project uses wxWindows and some funky wxWindows run-time class type info stuff):- main program includes BaseClass.h/cpp (and links to BaseClass.obj)- DLL includes BaseClass.h/cpp (and links to BaseClass.obj)- main program calls LoadLibrary and finds all classes that have been registered that are derived from type Plugin using this funky wxClassInfo stuffAt the moment I''m not really sure what''s going on.  Classes don''t seem to be exported anywhere, they''re just included everywhere.  It''s a bit of a mess.  But what I do know is that the BaseClass h/cpp is included into all projects, and if I change the values of some static members in the main program and print them out, and then also print them out in functions in the DLL, the values are different (which makes sense to me since it was linked into both).So I searched the forum and read a whole lot of posts about exporting classes and DLLs in general.  Okay, it all sounded good.  I changed the project around; I created a common header that defines the usual export declarations depending on whether I''m compiling the DLL or the main program.  Now the main program only includes the base class header.  But I''m getting link errors.  The linker can''t find any of the data members that are in the base class.  The class is defined as:class DLL_API BasePlan{   // ...}where DLL_API is the appropriate declaration.   I suppose if I had statically linked to the DLL export lib it would have found them..?  But I can''t do that as this project uses a plugin architecture where you can drop in DLLs into a directory and they''ll provide extra functionality; if they''re not there you don''t get that functionality.Does anyone have any suggestions please?cheerssam 
  I assume you are using VC, are you sure you are building a dll project? check project properties. also do you have the correct code generation option? ;  Hi,Thanks for the reply.  Yes, I''m using VC.  I''m definately building a DLL project (just checked).  I''m using dynamic run-time libraries everywhere (including for the wxWindows library).This thing is a bit of a mess and I''d really love to re-write it using a factory/interface style but I don''t think that''s an option as it "seems" to work as-is (I''m not in charge).sam;quote:Original post by izzo  Can I link to this class in my main program and then export the class from there so that all of my DLLs can use it?Yes, that''s possible, but it''s usually not worth the compiler contortions necessary to do it. A better plan is to create a separate DLL that contains the base class code and link both the executable and the original DLLs against that DLL.quote:- main program includes BaseClass.h/cpp (and links to BaseClass.obj)- DLL includes BaseClass.h/cpp (and links to BaseClass.obj)- main program calls LoadLibrary and finds all classes that have been registered that are derived from type Plugin using this funky wxClassInfo stuffAt the moment I''m not really sure what''s going on.What''s going on is that separate copies of the base class code are being created and used in the DLL and executable. This isn''t the best way to handle things (or even a particularly good way either). The downsides range from a simple maintenence issue (you should keep the DLL and executable synchronized with respect to changes in the base class''s code) to outright program incorrectness (particularly if the base class''s code uses global or static variables, which is a problem you''ve already noticed).Again, I would suggest moving the base class into its own DLL and having both the executables and the plug-in DLLs link against that. Then you should have only one copy of the base object''s static data and all should be good. ;  Ahh thanks (I was hoping that you''d respond, SiCrane, as you seem to be the resident DLL export ).  Woops, I meant expert, but I thought I''d leave that typo in. That''s what I suspected was happening.  The base class in its own DLL sounds like a good option; I''ll recommend that to the boss.Thanks!cheerssam