Sign in to follow this  
Valor Knight

Restructuring my program with libs and dlls

Recommended Posts

Valor Knight    182
Right now I am starting to restructure my program into components, so that it does not look as messy, seperate the engine from the game, and will make it easier to use. Currently I have started to move my sound handling classes into a dll, so far it is working. I understand why dlls are so nifty, if something in one needs to be changed in one of then, such as a bug, I can just update and change the dll. But, when linking the main program, it is looking for the .lib for that file andd including it (the one that is created with the .dll file), does that mean that if I change something significantly in the dll project, does the main project need to be recompiled to link to the new .lib created when the .dll was? I know having code in a dll suffers a little performance (am I right?). Does putting code in a .lib suffer any performance hit? I want to move my input handling, and any other engine component that rarely changed to a .lib to once again clean up my game and separate the engine from the game.

Share this post


Link to post
Share on other sites
bpoint    464
Quote:
Original post by Valor Knight
But, when linking the main program, it is looking for the .lib for that file andd including it (the one that is created with the .dll file), does that mean that if I change something significantly in the dll project, does the main project need to be recompiled to link to the new .lib created when the .dll was?

The main application only looks for the .lib from the DLL because it imports calls from functions within the DLL. You can change the internals of your DLL as much as you like, and relinking the original application is not necessary.

If you remove a function from the DLL that is called by the application, Windows will give you an error when the EXE is run because it is bound to it. GetProcAddress will simply fail.

Quote:
I know having code in a dll suffers a little performance (am I right?). Does putting code in a .lib suffer any performance hit? I want to move my input handling, and any other engine component that rarely changed to a .lib to once again clean up my game and separate the engine from the game.

Calling a function in a DLL is usually not any slower than if it was integrated into a .lib and linked directly with the EXE.

However, since Microsoft Visual Studio 2003, there is an optimization called "Whole Program Optimization" which will actually optimize code and function calls at the linker level. You get this benefit with .libs, but DLLs cannot be optimized. I can't say exactly how much performance is actually improved -- I've never timed it myself.

The one other benefit with .libs over DLLs (in my opinion) is that it makes one nice EXE. You don't have to worry about ensuring your DLLs are in the same location as the EXE, or if they're in the path. Debugging is also easier with a .lib than a DLL if you use delayed loading. Any breakpoints set within a DLL are invalidated until the DLL is loaded into memory, making debugging slightly annoying.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by bpoint
Calling a function in a DLL is usually not any slower than if it was integrated into a .lib and linked directly with the EXE.
Calling a function in a lib is one indirection faster than calling a function in a dll, because with libs you can resolve the precise locations of the functions at compile time.

Share this post


Link to post
Share on other sites
bpoint    464
Quote:
Original post by Anonymous Poster
Calling a function in a lib is one indirection faster than calling a function in a dll, because with libs you can resolve the precise locations of the functions at compile time.

Quote:
Original post by Troll
That's not true. Calling functions in DLLs is generally slower:


There is a difference between "not usually any slower" and "not slower than". I guess my English needs work. [rolleyes]

Yes, you incur a memory access fetch to lookup the address of the function in a DLL. On x86 this usually doesn't amount to much of a penalty, but other CPUs (as pointed out in the link in Troll's post) can't call the value of a pointer in memory directly, and require multiple instructions.

Share this post


Link to post
Share on other sites
Leadorn    100
If u changes a functions returns value or parameters that aren’t like before in numbers and stack space there will be a problem. Then u needs to relink.


if u aren’t using this nifty thing try it lets u compile to dll (#define TOOL_EXPORT) or import (#define TOOL_IMPORT) or the normal way compile the source with the project.

Also beware that the process and the dll and dlls have different memory allocators. So deallocated memory in the same dll/process as it was allocated.


#pragma once

#ifdef TOOL_EXPORT
#define TOOL_PREFIX __declspec(dllexport)
#elif defined(TOOL_IMPORT)
#define TOOL_PREFIX __declspec(dllimport)
#else
#define TOOL_PREFIX
#endif

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this