Wow! Lot's of bouncing around here - in the future, post only one question at a time (or at least keep them related)... Memory leaks - what they are, what causes them is totally different from DLL linkage...
Anyway, I'll see what I can do. So, you already know that in order to export a function (or class etc.) from a DLL, you need to export it. Furthermore, you already know that to use that function (or class etc.) you need to import it into your application. The following code snippet allows you to incorporate import/export functionality depending upon how you are #including the file:
//============================================================================
// This section #defines the JTK_EXPORTABLE and JTK_IMPORTABLE macros for DLL
// Import/Export specializations.
//============================================================================
#if defined( _MSC_VER ) && ( _MSC_VER >= 1200 )
# define JTK_EXPORTABLE __declspec( dllexport )
# define JTK_IMPORTABLE __declspec( dllimport )
#elif defined( __BORLANDC__ ) && ( __BORLANDC__ >= 0x0540 )
# define JTK_EXPORTABLE __declspec( dllexport )
# define JTK_IMPORTABLE __declspec( dllimport )
#else
# define JTK_EXPORTABLE _export
# define JTK_IMPORTABLE _import
#endif // _MSC_VER
//============================================================================
// Now we set the actual Import/Export decl_spec according to all of the
// previously identified #defines from above...
//============================================================================
#if !defined( JTK_USEAS_DLL )
# define JTK_CLASS // Either .LIB or directly added to project... Set to nothing!
#else
# if defined( JTK_BUILD_DLL )
# define JTK_CLASS JTK_EXPORTABLE // We're building the Tool-Kit as DLL's. Set to export...
# else
# define JTK_CLASS JTK_IMPORTABLE // We're linking into our project, the Tool-Kit was already
// built as a set of DLL's - so we set them all to IMPORT...
# endif // JTK_BUILD_DLL
#endif // JTK_USEAS_DLL
#if !defined( JTK_API )
# define JTK_API JTK_CLASS
#endif
Again, you already know the difference between the two from the tutorial, right? Anyway, this snippet essentially checks for a previous #define JTK_BUILD_DLL (implying the need to export) and JTK_USEAS_DLL (implying the need to import). Only #define JTK_USEAS_DLL and JTK_BUILD_DLL, or just JTK_USEAS_DLL or neither.
All this does is simplifies things for you by letting the pre-compiler determine which variety of function (or class) that you need.
Now, as for VS2008 specifics: Yes, there can be problems with this. When you want to export a function, you need to declare that function as extern "C" or you get the Microsoft compiler (and potentially version) specific variety. Not usually an ideal solution. Generally speaking, when I know I want to export several functions, I'll enclose the whole group as such:
#if defined ( __cplusplus )
extern "C" {
#endif // __cplusplus
void JTK_API _penter_manual( void );
void JTK_API _pexit_manual( void );
class JTK_API Foo {
public:
Foo( void ); // ctor...
~Foo( void ); // dtor...
...
};
#if defined ( __cplusplus )
}
#endif // __cplusplus
NOTE the JTK_API (see above snippet for its definition). When compiling the DLL, JTK_API will declare them as exportable; whereas when compiling an application that uses the DLL, it declares them as importable. By enclosing them in the extern "C" block, the functions are declared with C linkage (as opposed to C++ linkage) which makes them more compiler independent. C++ linkage (the default) is compiler/version specific; hence, the reason you've been hearing such things.
In addition, different compilers (read: vendors) still have different naming conventions - even for so-called standards. Thus the reason for the #ifdef _MSC_VER / __BORLAND__ checks above. Even different versions of the same vendor's compilers may be different!
NOTE: I don't believe that a class can be "imported" by DBP even if it were declared as JTK_API (in the example above). I could be wrong on this point, however...
NOW: as for the memory leaks - I give a pretty decent description of what causes *some* (especially in regards to GDK) memory leaks (and why)
here. A simplified description of a memory leak is this: memory was allocated (for some reason) by the operating system; but never released back to the operating system for later use...
I hope that helps you in understanding some of your questions - or at least gives you a bit more to go on...
JTK
PS: In case anyone is curious, no; the letters JTK are not my initials... :p - In reality, they are the initials for my Tool-Kit (Just-a-Tool-Kit)... Thought you'd like that bit of info!
EDIT: corrected error in logic description regarding JTK_USEAS_DLL/JTK_BUILD_DLL... Sorry for any inconveniances...
