   Export a class with DLL
  I was reading this tutorial http://www.codeproject.com/KB/DLL/RegDLL.aspx and it seems like it said that you can not export a class in a DLL without including its .h in the new project. Did I read this wrong? How can I export a class into a DLL.   
  This is correct.Quote:From C++ FQA LiteThe lack of a standard ABI (application binary interface) has another consequence - it makes shipping C++ interfaces to other teams / customers impractical since the user code won't work unless it's compiled with the same tools and build options. We've already seen another source of this problem - the instability of binary interfaces due to the lack of compile time encapsulation.IMO DLLs should expose a more abstract interface than C++ classes can provide.  True C-style opaque types, for example.  Then could can actually *gasp* change the implementation of those opaque types without recompiling everything.   ;  Exporting a class into a DLL is easy if you know that you'll always be using the same compiler later. In that case adding a __declspec(dllexport) will be all you need to do. Usually one does this with a macro (something like DLLIMPORTEXPORT) which one defines differently according to whether one is building the DLL or using it. That way, only one version of the header file needs to exist, which is a good thing.If other people might be using your DLL (so you don't know what compiler will be used), you need to export a pair of extern "C" create/destroy functions. Half of the more modern Windows API is class-based and works like this.Of course, you still always need a header file, so the compiler knows what your class looks like. Otherwise, it doesn't know what to do if you call a member function.   ;Quote:Original post by simotixHow can I export a class into a DLL.quick tutorial;Quote:Original post by CadetUmferQuote:From C++ FQA LiteThe lack of a standard ABI (application binary interface) has another consequence - it makes shipping C++ interfaces to other teams / customers impractical since the user code won't work unless it's compiled with the same tools and build options. We've already seen another source of this problem - the instability of binary interfaces due to the lack of compile time encapsulation.That is not related to simotix' question whether you have to distribute the header file of a class in order to use it.Simotix: The .h-file is needed because in C++ type information is evaluated at compile time ("static typing"). Without a declaration of your class, the compiler can't know which functions can be called and what members your class has, but that information is needed in order to emit an exebutable file (or just .exe file, on windows). Note that any equivalent declaration is valid, that is, if the client declares a class with the same name, members, and which derives from the same classes, then the client can use that definition (works also for functions; you see that often in code that loads OpenGL extensions), in other words, the declaration must have the same signature.Question: Do you know virtual functions and interface classes in C++?;  I know virtual functions, however, by interface classes do you mean a pure virtual base class? If so, yes I do.I will always be using the same compiler. Basically, here is what I want to do.I want to have a solution with three projects. The first project is all of my main code/classes, compiled into a dll. The second project is my game which will use those classes, the third is tool set which will use those classes. I do not want to have to create the header for every one though.   ;Quote:Original post by simotixI do not want to have to create the header for every one though.Well you can stick all the classes in a single header if you prefer, but the class definitions for those classes in the DLL will need to be in a header that's accessed by the exe+tools somewhere - otherwise they'll have no idea what the DLL contains.;  I'll try to keep it short:Project 1, (probably the base or something like that):// Project.h, at least a global file#ifdef PROJECT_EXPORTS#define PROJECT_API __declspec( dllexport )#else#define PROJECT_API __declspec( dllimport )#endif// timer.h#include "project.h"class PROJECT_API Timer{public:   Timer();   virtual ~Timer();   virtual void do_work() = 0;};// Timer.cpp#include "timer.h"Timer::Timer(){}Timer::~Timer(){}This is a setup you will do for all classes: Separate class definition and implementation. The most important thing is to include the project.h in each header that shall export a class.// Game.h#include "timer.h"class Game{   Timer m_timer;}But in any case, do not generate another header file that simply defines those exported classes. It's a waist of time and increases the chance of errors (like changing the header for the dll, but not the exported one).   ;  If I did that, then I would be able to include only the .DLL and not need to copy over header files to other projects?   ;Quote:Original post by simotixIf I did that, then I would be able to include only the .DLL and not need to copy over header files to other projects?You do not copy header files to other projects. You set the include path for your exe so that the compiler knows where to find the header file(s) for your DLL when you include it.   