2. Dynamic Link Library ( DLL ) Approach

The first approach was to package the class as Dynamic Link Library. Microsoft compiler directive _decl spec(dll export) does the same.


We can modify our FastString class to be a DLL now by using the directive.

class _declspec(dllexport) FastString {

    char *m_psz;

public:

   FastString(const char *psz);

   ~FastString(void);

   int Length(void) const; II returns # of characters

   int Find(const char *psz) const; II returns offset

} ;


This allows run time mapping of the function to its address in the memory. The clients imports the library stubs are added to the client code. When the client code is executed the DLL is loaded in memory if not loaded and functions are mapped with address location in memory.

Problems solved with this approach:

• True re-usable component is evolved. 

          The machine code for the class needed to be executed only once in the users Hard disk to load the DLL in the memory. Any further reference to the library from any other application will be given the handle to the read only executable memory page.

Immediate Challenge ahead:

• The approach is still compiler dependent.

          "Name Mangling" refers to the process of changing symbolic names of the entry points of the DLLs to allow function and operator overloading. This scheme is very much vendor dependent. The GNU C++ compiler naming schemes would not match  Broadland C++ scheme. This would mean that while linking the DLLs from other C++ compilers we would run into issue. 

          Even if  we ignore the above fact, we have to deal with the generated code issue of the compilers. Each C++ compilers generates untouchable code in the background. The exception handling is a very good example. A exception thrown from Microsoft compiler cannot be manager GNU C++ compiler. 

• There is still dependency of object size in the client.

          Lets assume a situation where FastString was updated to have greater speed and in the process a new member is added to the class.

// faststring.h version 2.0
class __declspec(dllexport) FastString {

const int m_cch; // count of characters was added to store the string size
char *m_psz;
public:
FastString(const char *psz);
-FastString(void);
int Length(void) const; II returns # of characters
int Find(const char *psz) const; II returns offset

} ; 

           This improved version FastString 2.0 is provided to all the clients with the application compiled with it. Every thing would work fine except if the client uses other applications compiled with the old DLLS FastString 1.0.

The applications compiled with old DLL will crash because C++ does not provide binary encapsulation. Which means clients compiled with DLLs should have the complete of the amount of memory it has to create for the object. The application compiled with old DLL know that it has to allocate 4 bytes for the pointer m_psz and do not know about the new attribute m_cch. The clients complete with new DLL have complete information. Hence , when we will try to create an application with out of sync DLL , it will crash because it will create a memory location of 4 bytes which will be filled with 8 bytes.