home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / tools / 2190 < prev    next >
Encoding:
Text File  |  1993-01-21  |  1.5 KB  |  38 lines
  1. Newsgroups: comp.os.ms-windows.programmer.tools
  2. Path: sparky!uunet!microsoft!hexnut!gregde
  3. From: gregde@microsoft.com (Greg Demichillie)
  4. Subject: Re: borlandc++ and MSC++ DLLs
  5. Message-ID: <1993Jan21.181354.12803@microsoft.com>
  6. Date: 21 Jan 93 18:13:54 GMT
  7. Organization: Microsoft Corporation
  8. References: <C0wsLI.Dwy@fig.citib.com> <C0xJn7.2y2@panix.com> <749@lax.lax.pe-nelson.com>
  9. Lines: 26
  10.  
  11. In article <749@lax.lax.pe-nelson.com> twbrown@PE-Nelson.COM (Tom W. Brown) writes:
  12. >Currently the _only_ solution is to recompile the library (i.e. whoever
  13. >does this must have source code) using the BC3.1 compiler to generate a
  14. >Borland compatible version of the DLL.  This is why most 3rd party DLL's
  15. >either come with source or ship different flavors of the DLL depending on
  16. >which compiler is being used.
  17. >
  18.  
  19. Correct.  This is one of the many reasons that I don't think it's a 
  20. good idea to export a C++ interface via DLL.  The other problems are
  21. that any distinction between public and private is lost, all member
  22. functions are available and that any change in the size of objects or
  23. their interfaces means that you not only have to recompile the DLL but
  24. any clients apps as well.  This negates one of the biggest advantages
  25. of DLLs in the first place.
  26.  
  27. If you want to implement a DLL in C++, that's great.  But you really
  28. should just export a C language interface.
  29.  
  30.  
  31. -Greg
  32.  
  33.  
  34.  
  35. -- 
  36. Greg DeMichillie          Microsoft AFX         
  37. gregde@microsoft.com      All opinions are mine, not Microsoft's
  38.