Advertisement

DLL related question

Started by April 14, 2002 05:27 PM
16 comments, last by porthios 22 years, 8 months ago
I have not tried the "extern ''c''" approach, so ill give it a try, and see what happens, If that does not work with my functions, ill try the c++ approach using classes. Thanks for the help again
Ok, the "extern ''C''" apptoach works, and I thank everyone for helping. But just a few more questions:

1: Whats the downside of using DLLs, is there a lot of overhead, negatives, etc, when using them. I want to know because the way I was gonna make something, there would be alot of DLLs used.

2: what does extern "c" really do? I was just curious (I think ill go look it up too, but someone can still reply)
Advertisement
extern "C" tells the C++ compiler (namely, cl.exe) not to mangle your function names. function names are mangled in C++ to allow for such things as function overloading.

the only real downside i can think of when using DLL''s is that function calls have to go through the IAT (import address table).

i.e. call:[mem] instead of call:[near32] .

i don''t know the performance differences on today''s processors, though.

and you need to make sure the application can find the DLL at run time.


peace.

To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.
To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.
A dll that is statically linked to an exe is loaded into the address space of the process by the OS at start up and the import address table (IAT) fix ups also happen at that point. Once that has been done, there is no additional overhead for accessing the code in the dll. If a dll is accessed using LoadLibrary and GetProcAddress to assign functions to localized function pointers, there is some overhead in the extra effort to load the dll. With that approach it''s best to set up your function pointers during program initialization - just that one time rather than every time you want to call the function. Once reason for using this approach to a library is in cases where the targeted function might not be available (like with undocumented functions). So if GetProcAddress returns null, you can provide an alternative solution or handle the situation in some other way.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
I have another problem:

When using DD7 in a program, it works alright. When I try to use it in my DLL, it just doesnt seem to work, what would I have to do to get it working? Im getting the errors "undefined reference DirectDrawCreateEx" and another "undefined" error. I was wondering why it does this with DLLs, and not normal programs.
Can someone please tell me how to make a dll in dev-c++. I can''t figure it out
Advertisement
quote: Original post by porthios
I have another problem:

When using DD7 in a program, it works alright. When I try to use it in my DLL, it just doesnt seem to work, what would I have to do to get it working? Im getting the errors "undefined reference DirectDrawCreateEx" and another "undefined" error. I was wondering why it does this with DLLs, and not normal programs.


Those sound like compiler errors. Did you remember to link with the appropriate lib files?
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
I have them linked correctly, using Dev-C++, go to your project settings and select whatever LIBs you need, and that should be it, Funny thing is, it works when I compile it for a normal EXE, maybe itll be fixed later on?

This topic is closed to new replies.

Advertisement