- Forum
- General C++ Programming
- Classes and DLLs
Classes and DLLs
If I'm not mistaken, DLLs only store code. Just functions. Then how can class information be hidden? Or it's not hidden? When a company creates a commercial DLL, it doesn't want people to know how the functions are implemented. But what about classes? For example, if the package uses OOP, there has to be a .h file containing class definitions, right? Or DLLs can't be used with OOP and contain member functions? How does it work?
Well, I always thought that DLLs are in a way the C/C++ equivalent to Java's Jar-Files. If so then a DLL acts similar to a container or package of multiple code files and can thus contain all kinds of known C/C++ code files including both std .c/.cpp files and header files. Shout at me if all that is nonsense but otherwise DLLs would not match OOP design requirements. I think DLLs must be capable of storing entire projects since Visual Studio C++ creates a new project for DLLs to put code files into.
Correct me if I'm wrong here
Correct me if I'm wrong here
Last edited on
Classes need to be declared in headers in order to be used, only if they are expected to be used by whoever uses the library (e.g. std::string). Otherwise, how is the compiler supposed to know what members Class contains? Classes used internally by the library (e.g. a class called Token in a library for parsing) don't need to be known by the linking application, and so they don't need to be declared in the header that is provided with the compiled library.
Classes should be declared in a header, not defined.
Methods are just like any other function (the this pointer is actually just an implicit parameter), and like any other function, the compiler need to know what parameters they take and what they return in order to do type-checking.
So, in summary, this is what the layout looks like:
Public header:
* Public class declarations (i.e. only containing members and method declarations).
* Public function declarations.
* Template function definitions.
* Public global variable declarations.
Library:
* All function definitions, including class methods, but excluding template functions.
* All global variable definitions.
Note that private class declarations aren't included in the library, because classes don't exactly exist in compiled code. In reality, objects are arrays of differently-sized data, so members are accessed by adding offsets to a base address (the address of the object).
Classes should be declared in a header, not defined.
Methods are just like any other function (the this pointer is actually just an implicit parameter), and like any other function, the compiler need to know what parameters they take and what they return in order to do type-checking.
So, in summary, this is what the layout looks like:
Public header:
* Public class declarations (i.e. only containing members and method declarations).
* Public function declarations.
* Template function definitions.
* Public global variable declarations.
Library:
* All function definitions, including class methods, but excluding template functions.
* All global variable definitions.
Note that private class declarations aren't included in the library, because classes don't exactly exist in compiled code. In reality, objects are arrays of differently-sized data, so members are accessed by adding offsets to a base address (the address of the object).
So if a commercial company sells a package that uses OOP, it has to give the users the possibility to open the .h files and see the class declarations (in other words, it exposes this part of the source code)?
You're not getting it.
Public headers only need to contain classes that will be used by the users (programmers) of the library. In other words, it makes no difference whether the users can see the declaration in the header or not, because they need to know, one way or another, what public members and methods are inside the class in order to use it (and to link to it).
For example, would you be able to know a class in a bignum library has a method bignum add(bignum) without looking at the declaration or the documentation (which usually gives even more information)?
What you're proposing is like selling cars without any controls or gauges, and still pretend people to drive them.
Public headers only need to contain classes that will be used by the users (programmers) of the library. In other words, it makes no difference whether the users can see the declaration in the header or not, because they need to know, one way or another, what public members and methods are inside the class in order to use it (and to link to it).
For example, would you be able to know a class in a bignum library has a method bignum add(bignum) without looking at the declaration or the documentation (which usually gives even more information)?
What you're proposing is like selling cars without any controls or gauges, and still pretend people to drive them.
Last edited on
Why do you think source code would be exposed?
If there are end-users having purchased some middleware software package that contains DLLs etc. then they are normally given a suitable specification sheet or documentation. I do not even dare thinking an end-user to be forced to take a look into the respective source code to be capable of using it. And I do not think there are companies doing it that way because it would be inefficient and not worth buying such a software package.
If there are end-users having purchased some middleware software package that contains DLLs etc. then they are normally given a suitable specification sheet or documentation. I do not even dare thinking an end-user to be forced to take a look into the respective source code to be capable of using it. And I do not think there are companies doing it that way because it would be inefficient and not worth buying such a software package.
Topic archived. No new replies allowed.