//My Library class MyCoreClass; class MyOtherClass; __declspec(dllexport) MyCoreClass* __stdcall CreateMyCoreClass( );

This initializes my core class. In another file I do this...

//Other Program MyCoreClass *MyCoreObject; MyCoreObject = CreateMyCoreClass( ); MyOtherClass *MyOtherObject; // This doesn't seem to work - I get a linking error MyOtherObject = new MyOtherClass( );

If I only want to export the core class how would I go about initializing the other class. Do I need to create a function in the core class that returns a pointer to a MyOtherClass? Example:

//My Library MyCoreClass { public: MyOtherClass *GetOtherClass( ); };

//Other Program MyOtherClass *MyOtherObject; MyOtherObject = MyCoreObject->GetOtherClass( );

Any help would be appreciated. By the way I am trying to create a simple game engine library just to see how they work.

[This message has been edited by HeardTheWord (edited January 24, 2005).]

quote:

---

Originally posted by HeardTheWord:
MyOtherClass *MyOtherObject;
// This doesn't seem to work - I get a linking error
MyOtherObject = new MyOtherClass( );

---

That's because your MyOtherClass either isn't defined, or exported, its .lib file isn't being linked in, or some combination of those three.

quote:

---

If I only want to export the core class how would I go about initializing the other class. Do I need to create a function in the core class that returns a pointer to a MyOtherClass?

---

That should work, as long as the main program knows what a MyOtherClass looks like, even if it isn't explicitly exported. Why don't you want to export it, if you want to want access to it externally anyway?

One handy trick for .dlls in general is the following:

// your dll's .h file #ifdef MYDLL_EXPORTS #define MYDLL_API __declspec(dllexport) #else #define MYDLL_API __declspec(dllimport) #endif class MYDLL_API MyCoreClass { ... }; class MYDLL_API MyOtherClass : public MyCoreClass { ... }; // prototypes int MYDLL_API MyFunction();

Then in your dll's project, you define MYDLL_EXPORTS in your preprocessor, but not in your main app's project. You then include the dll's .h file in both projects, and the dll code will see the class and stand-alone functions as exported, and the main app will see the class and stand-alone functions as imported (you still have to link to the dll's .lib file) - and no .def file is needed. Using the above example .h file, both your code examples in your post should work.

------------------
Brian

Just a quick question. Is their any reason not to export a class? Why wouldn't you want to export everything or would that create a larger .lib file? Just wondering why most libraries don't export a bunch of classes or functions.

[This message has been edited by HeardTheWord (edited January 24, 2005).]

quote:

---

Originally posted by HeardTheWord:
Just a quick question. Is their any reason not to export a class? Why wouldn't you want to export everything or would that create a larger .lib file? Just wondering why most libraries don't export a bunch of classes or functions.

---

It won't make your .libs any bigger (except by a few bytes where the export table is). The amount you export is purely up to you, and is generally an organizational/maintenance issue. For the same reason you usually don't make all a class's member functions and member variables public, you don't make all things exported from a .dll - rather, you only make available what the outside world really needs to use it. Just easier for the user, as well as easier to maintain, I guess. In a CD player, the user can start, stop, skip forward, skip backward, pause, eject, and adjust the volume. The user doesn't (and shouldn't) control the spin speed of the disc nor the movement and intensity of the laser/lense, let alone access and control over the individual transistors, resistors and diodes on the circuit board. Think of your .dll (and your classes) in a similar manner, and only provide enough of an external interface to let it do its job. I'm not saying to be over minimalistic - if it would be handy for the main app to have access to a class, go ahead and export it.

It also depends on the .dll. Some dlls have dozens or hundreds of exported functions, and it's still a good design in those instances. Some of the Windows system .dlls are good examples of this.

------------------
Brian