I have a quite basic question.
You can use load-time dynamic linking or run-time dynamic linking in your DLL in the same way as in the executable. The only restriction is not to call LoadLibrary from your DllMain function to avoid deadlocks.
Solution 1. A DLL file shouldn't have a main fucntion - it implies it has an entry point and can be run in isolation - which it shouldn't. Since you created the DLL, I'd rename the function "ModString" or something which describes what it does to the parameter - that way the code using it is more self documenting.
There is almost no overhead to having a separate DLL. Basically, the first call to a function exported from a DLL will run a tiny stub that fixes up the function addresses so that subsequent calls are performed via a single jump through a jump table. The way CPUs work, this extra indirection is practically free.
The main "overhead" is actually an opportunity cost, not an "overhead" per-se. That is, modern compilers can do something called "whole program optimization" in which the entire module (.exe or .dll) is compiled and optimized at once, at link time. This means the compiler can do things like adjust calling conventions, inline functions and so on across all .cpp files in the whole program, rather than just within a single .cpp file.
This can result in fairly nice performance boost, for certain kinds of applications. But of course, whole program optimization cannot happen across DLL boundaries.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With