1

I'm new to using DLL's in C++ and I am wondering how to sucessfully load and use classes contained in a DLL without getting a "corrupted stack", a "null pointer" or any application crash ^^. This is a bit confusing to me for now. Even if it might be safer I don't want to use interface class because it seems too complicated to use. I know that I should have the same include in both DLL and application to prevent crashes. That means that my include file should mention members name.

Here is the problem :

I want to distribute my software (DLL + include file) and I don't want my customers to see the architecture of my project. But the only class I want to export from my DLL has as member, objects from other classes. So my class is dependent of other classes and so on in cascade.

Is it possible to provide only one include file of one class with just useful methods without having risks of crashes ? If no, what solutions might fit my needs ?

Thanks

rrirower
  • 4,338
  • 4
  • 27
  • 45
PadThai
  • 225
  • 1
  • 2
  • 5
  • http://stackoverflow.com/questions/27998/exporting-a-c-class-from-a-dll – xxbbcc Aug 11 '15 at 19:47
  • Thank you, that's an interesting thread but I'm looking for a method that is not involving the use of an interface class. I am wondering if it is even possible. – PadThai Aug 11 '15 at 20:26
  • 1
    @PadThai: Don't use an interface class, use bare functions for the interface. That way you aren't dependent on vendor- and version-specific variations in C++ class layout. Windows has a C ABI, but C++ objects are not so standardized (except the portions covered by COM, which does not include data members). – Ben Voigt Aug 11 '15 at 21:26

1 Answers1

0

FIrst of all, if you use the same include in DLL and in the application using it, if both were compiled with the same compiler and compatible settings, and both use the same runtime library (DLL one, not statically linked), you should have none of the problem you fear.

If you want to hide details of your DLL and provide an alterered, simplified header to the DLL users, you work on your own risk. For example, if there are data members missing (even private ones) of if there are virtual functions missing (even private ones), then it might probably crash, or worse, corrupt something without being noticed. So I'd strongly advise you not to consider this approach unless you're very very experienced with the assembler generated by your compiler.

If you want to hide implementation details of your class, the best approach would probably to design your library around the PIMPL idiom.

Christophe
  • 68,716
  • 7
  • 72
  • 138