Re: My exe is using functions from a DLL which are not exported
On 7/26/2011 12:46 PM, Mikel Luri wrote:
Maybe I didn't make myself clear, but before adding the static function
that makes the error happen to the class in the dll, I was using other
non-static functions of the same class from the exe, without errors.
That's what made me ask the question, the fact that I seemed to have
been using "non-exported" functions from outside the module.
The "problem" class is an abstract class, and its derived class. None of
them is exported as a whole, and neither are the functions I've been
using from outside the module. They are used in another class which is a
container of pointers of such classes, and which is exported.
class A { }; // Abstract
class B: public A {};
class C: public A {};
class D: public A {};
class EXPORT_CLASS CContainer:public CArray<A*> {};
As I already mentioned, the functions I'm using are defined in the cpp
files, and I can't find them in the exports section of the dll in
Dependency Walker, nor in the imports section of the exe.
It's rather strange. Maybe I'll try to replicate it with a simple
solution, to see what's happening.
I've created a sample solution which reproduces the issue. I've created
pretty much the class structure of my previous post in a dll, then used
it from my exe file.
If you want to take a look at it, you can find it in the following link
(it's a VS2008 solution):
http://www.filedropper.com/exporttest
Hi, I downloaded your example and compiled it and it woked as you
explained.
What is inside your project is:
- the dll contains and abstract class A
- two derived classed B and C derived from A.
- a carray class derived CMyCollection of pointers to A's classes. The
CMyCollection is exported in a regular way.
Your question following:
"...But then I added a function (static) to
one of the classes in one of the dlls, to use it from the exe, and the
linker says it doesn't find it"
That's ok. What you're exporting from your dll is only the class
CMyCollection and not A, B and C. So if you add a method on B or C,
whatever method you like, you cannot see it on the exe. The linker gives
the error because you are not allowed to use any B, C methods, because
they are not exported.
Put in other words, what you're playing with in your exe is
CMyCollection and pointers not the single A, B, C classes.
Then if you are asking why you can use the A and A's methods inside the
exe I think because you're using pointers. Indeed you include A.h only
in the exe and the real stuff about B and C's methods are happening
inside the dll (CmyCoollection::Init).
I'll give a simple example:
Move away the concept of c++ class. Suppose your dll is exporting a
single function
tyepdef int (*FnPointer)(int, int)
__declspce( dllexported ) FnPointer* GiveTheNthElement( nth );
You provide to the caller the declaration of FnPointer, as simple of
types of function pointer.
At this point from your dll you're exporting only the
GiveNthElement(...) function. In your exe you can call regularly the
GiveNthElement(...) function and retrieve a pointer.
To use this pointer you don't need the other functions the pointer
retrieved points to, you can call and use the funtion pointer normally,
based on the declaration.
FnPiointer* ptr = GiveTheNthEleemnt( 10 );
int Count = ptr( 0, 10 );
The real stuff happens at run time and not at compile or linking time.
Is it clear?