make a static or dynamic lib?!
Author
well... I'm planning to split up my engine into smaller libraries that I can reuse into other projects, like my LogSystem and so on... but should I write them as a .dll file or a .lib file what should make up the rules for wich one to choose?
To be honest, I don't think it matters that much, but before you decide, consider a few factors. If you include it as a static library then all your entire project will need recompiling relinking if you change the library. If you choose dlls, then you could simply exchange the bugged dll for a bugfixed version (assuming you keep the interfaces the same). However, you then get into the realm of having to check each version of the dll you try and load to ensure that the user has the correct one for your application. In a worst-case scenario, the user could end up with several versions of a dll, each version of which is slightly incompatible.
As far as best practice goes, the trend tends to be statically link the core components (such as logging, etc) and then throw out components that can be exchanged between projects (eg: game/renderer) into a dll. This way, the majority of the engine core remains the same, it's just the subsystems that can be hot swapped.
EDIT: It's 7am
[Edited by - evolutional on August 27, 2004 1:12:47 AM]
As far as best practice goes, the trend tends to be statically link the core components (such as logging, etc) and then throw out components that can be exchanged between projects (eg: game/renderer) into a dll. This way, the majority of the engine core remains the same, it's just the subsystems that can be hot swapped.
EDIT: It's 7am
[Edited by - evolutional on August 27, 2004 1:12:47 AM]
Quote:Original post by evolutional
If you include it as a static library then all your entire project will need recompiling if you change the library.
No. Your entire project will need relinking, only the code thats had bugs fixed will need to be compiled, which is considerably less work than recompiling the whole thing. This method does present a problem for users if they only have the binary and you want to distribute a bugfix. To distribute a patch you need to send the whole new binary (or some magic diff type thing), whereas with a dll you just replace the single bug fixed dll.
That advantage doesn't necessarily warrant making a dll.
Thanks Doc, I missed that one (being 7am and at work already - fun) [smile].
As I said before though, I'd still throw all the core components into the main exe in the form of static libs. Of course, you'll benefit from having a reusable static library for logging or memory management (or whatever) that you can then drop into other projects with ease. Throwing everything into dlls will just overcomplicate things, IMHO, so select which components will change on a per project basis and consider using them as dlls.
As I said before though, I'd still throw all the core components into the main exe in the form of static libs. Of course, you'll benefit from having a reusable static library for logging or memory management (or whatever) that you can then drop into other projects with ease. Throwing everything into dlls will just overcomplicate things, IMHO, so select which components will change on a per project basis and consider using them as dlls.
If the code is for your own consumption then use static libs otherwise dlls. The only bad thing about static libs is that you have to write in all those libs that your static lib is using which is a pain but not as much as copying and versioning dlls for your apps. Heck you could just write a list of libs to include into an IDE in your lib main source file and copy that everytime. I think you can also drag and drop the libs into your project in the IDE instead of writing them in yourself. Also, with static libs you don't have STL issues across dlls. Plus to deal with the whole dll syntax and memory leaks. If however you need to switch things at runtime you could go with dlls then.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
