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.

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.

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.

That's not true. Calling functions in DLLs is generally slower:

Some info from an MS employee

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.

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