I have been throwing stuff together in a small test game over the past 6 months or so, and right now everything is in the one project. I would like to learn more about creating an "engine" for reusability and I am trying to figure out the best way to do this.
Static Libs are obviously a tiny bit faster, as they are compiled in rather than loaded at runtime, but that really does not matter to me. The advantages of DLLs over static libs seems rather large. So im wondering what the best approach/most used approach is for a "game engine".
I am using Ogre3D (rendering engine) which supports dll plugins that it loads and what not, but I would like to write my dlls where I could basically use them anywhere. So would my best bet be to write individual DLLs for each portion of my sample engine, such as sound.dll, gui.dll, etc? Or would I be better served by creating one large dll, deemed engine.dll or something? I am assuming the best approach would be to write something like...engine.dll for the general structure, then compose it of other dlls such as sound/gui/input/etc.
Would it be silly of me to write my dlls independently of Ogre's Plugin system? My Sound relies on the FMOD library, my GUI relies on the CEGUI library, and so on. I mainly just want to create my engine to a point where it is easily usable with the functions I need from the individual librarys.
If you are creating DLLs for re-usability it makes sense to split it up into self contained units of functions. Thus, if you have a general sound library that, for example, plays wav files, that could be separated out as sound.dll if you think lots of other programs might make use of that particular library. Likewise for anything you think would be re-usable elsewhere.
However, if it is mostly the case that the only people using your sound routines are those who will also load the rest of your game engine (or most of it) dll, I see little point in having so many separate libraries. I can see the sense in having engine.dll so that many games can be created from a single engine but not from splitting up the rest unnecessarily.
Related
I recently decided to take a look at 2D graphics with C++, using MinGW on Windows 7.
Since I was only going to need 2D graphics any library would be viable more or less (OpenGL, SDL, etc..). I decided to take a quick look at a few and check how easy they'd be to get working on windows with MinGW.
I soon noticed every library I tested (which were Cairo, SDL and GTK+) required tons of dll files in order to work. After compiling even a simple program from something like a tutorial it would give me like 5 or 6 different dll errors, forcing me to copy all of them into my program's working directory for it to even run.
Of course my program worked, but it's very cubersome to have this many DLLs just for a simple program. Making the program run on someone else's computer would require to ship all those DLLs along with it as seperate files, plus other DLLs that I got globally installed but others don't.
It just seems so weird that something as popular as C++ would be so annoying to use because of all the DLLs required... Am I doing anything wrong? Could there be some magical solution to this problem? Some tool to minimize or even completely eliminate these complications? It'd be cool to have to use fewer DLLs for my application. Of course I won't be able to omit DLLs completely, but at least reducing the amount to a single one (one library = one DLL) or having the possibility to organize them in a subfolder of their own would be awesome.
Of course my program worked, but it's very cubersome to have this many DLLs just for a simple program. Making the program run on someone else's computer would require to ship all those DLLs along with it as seperate files, plus other DLLs that I got globally installed but others don't.
If you're making an installer for your program, the installer should take care of installing the DLLs right alongside your program. It's pretty common practice, and won't be inconvenient for your user at all. If you're just distributing a zip file with your app in it, just keep the DLLs in the folder you're zipping up (also a pretty common practice).
It's also worth noting that you'll already have to send DLLs with your app. GCC apps need libgcc_s_sjlj-1.dll and libstdc++-6.dll. MSVC apps, if I recall correctly, rely on the Visual C++ runtime library. A few more graphics libraries aren't likely to bother the user at all.
Am I doing anything wrong?
Nope, this seems like business as usual to me. I recommend you continue your project without worrying too much about the DLLs.
Could there be some magical solution to this problem? Some tool to minimize or even completely eliminate these complications?
You could look into a DLL/EXE packer. It's highly unrecommended, though, because antiviruses tend to not appreciate the modified EXEs. (A lot of malware uses packing techniques, so antiviruses are often suspicious of such packed apps by default.)
at least reducing the amount to a single one (one library = one DLL)
Technically you might be able to, but you'd probably need to rewrite the graphics library in question since right now it's set up for multiple DLLs. I really don't recommend this either; the DLLs are separate because they're meant to be. They offer different functionality (for example, a quick glance at GTK+'s changelog showed mentions of libraries for SVG, JPG, and other file formats, as well as a lot of backend stuff to interface with the host OS, printers, etc.) so they're encapsulated into different libraries. In some cases (libjpeg) these "sub-libraries" are even written by a different group, and the graphics library you're using just calls certain functions from the "sub-library".
If you're really that insistent on having just one DLL, I think you're better off looking for some little, minimal-functionality library. Since you just want 2D graphics you might be able to get away with that.
or having the possibility to organize them in a subfolder of their own would be awesome
Unfortunately you can't do this.
Perhaps some of you people have heard of http://suckless.org/ and their set of Unix tools. Basically, they're a set of programs that each aim to do one thing but do it well, while still being as simple and resource-light as possible.
I've been trying to find a way to reproduce this style of programming on Windows with C++ but all the libraries I know of would produce binaries that are huge with respect to their function. Even the simplest of anything Qt, for example, is generally several megabytes large. I'm not against packaging dependencies along with distributables but I wouldn't want to do it to that level.
Binary size is not one of my main goals but simplicity is and big libraries like these are, by construction, not simple. If binary size were your primary concern you could use runtime compression just like kkreiger or malware.
A possibility would be to go commando and use only ISO Standard C++ libraries but rebuilding a sockets or networking system for a small single-purpose application is not really something anyone would want to be troubled with.
For some reason I thought there was some general-purpouse library that Windows developers could count on everyone and their grandma having readily accessible but now I don't know if anything like that exists. What can you use to write code that adheres to the Unix Philosophy but for Windows targets?
You should target the Win32 API directly. You can't get much lower level than that. In the Windows world, everything directly or indirectly wraps the SDK functions, including the so-called "standard C++ libraries".
Alternatively, you could use something like MFC or WTL, which are relatively thin C++ wrappers over the Win32 API. Because of the overhead of the class libraries, such programs will be slightly smaller than those created using only the SDK, but nowadays, the actual overhead is completely insignificant.
The desires expressed in your question are precisely why I learned and still use the Win32 API today, so that's definitely what I would go with. Plus, your programs will look and feel native, which is way better than the crap most "cross-platform GUI toolkits" put out. The advantages of this can't be underestimated.
But if you just open up Visual Studio and compile a simple little SDK "Hello World" app, it'll still be awfully large. Kilobytes, to be sure, but that still seems like a lot for about the simplest app imaginable. If you really need to cut things down further, you can try telling Visual Studio not to link to the C runtime libraries and define your own main entrypoint. This does mean that you'll have to implement all of your own startup initialization code, but this can reduce the size of a trivial app substantially.
Matt Pietrek had this same idea some years ago, although you'll probably want to take time to "modernize" his original code significantly if you decide to go this route.
FLTK is a popular cross platform minimal gui toolkit.
Or a popular alternative if you don't need too much detailed interaction is just to fire up a minimal embedded webserver and do all the 'gui' in html in a browser.
I'm not sure if I am going about this the right way. I am making some c++ classes to use in 2 apps. I am going to have to compile them to be used in a Cocoa app and later be compiled for use with fastcgi.
Should I create a dynamic library?
If the source files have to be compiled with different conditional compilation settings to work in the two applications, you'd better ship the source and compile it along with the apps themselves.
Otherwise, you can create a library and ship the compiled versions along with the headers for compilation of the apps. Whether the library should be dynamic or not depends on your situation. If you don't need to update the library separately without recompiling the executable, a simple static library is probably a better choice.
Don't forget that you have static library as an option too. On some platforms dynamic libs come with a bunch of annoying baggage. They're also slightly slower (though this is usually beside the point). They also can't be replaced without recompiling the program (you might be more concerned about this in a web environment). Finally, when you're only running one of the programs on a computer you gain nothing by making the lib dynamic...and little when there's only two.
If you want to share multiple C++ class among projects you should typically place them in a class library. Not familiar with Cocoa though.
If you have many classes, then shared library. Make sure to use only abstract classes and no code in public headers (templates are OK). Provide factories (or plain functions) to instantiate the objects.
If that sounds like too much coding for you then, well, modern version control makes it rather painless to simply re-use the files in several projects, living in the same repository.
P.S. Another factor to consider is how many people work on the project. Shared library is an extra responsibility. If you have a person to take care of it, then it might be worth doing simply from organizational point of view.
I am about to attempt reorganizing the way my group builds a set of large applications that share about 90% of their source files. Right now, these applications are built without any libraries whatsoever involved except for externally linked ones that are not under our control. The applications use the same common source files (we are not maintaining 5 versions of the same .h/.cpp files), but these are not built into any common library. So, at the moment, we are paying the price of building the same code over-and-over per application, each time we intend to release a version. To me, this sounds like a prime candidate for using libraries to capture the shared code and reduce build times. I do not have the option of using DLL's, so the approach is to use static libraries.
I would like to know what tips you would have for how to approach this task. I have limited experience with creating/organizing static libraries, so even the basic suggestions towards organization/gotchas are welcome. Maybe even a good book recommendation?
I have done a brief exercise by finding the entire subset of files that each application share in common. As a proof of concept, I took these files and placed them in a single "Common Monster" static library. Building the full application using this single static library certainly improves the build time for all of the applications, but should I leave it at this? The purpose of the library in this form is not very focused and seems like a lazy attempt at modularity. There is ongoing development with these applications, and I'm afraid this setup will cause problems further down the line.
It's very hard to give general guidelines in this area - how you structure libraries depends very much on how you use them. Perhaps if I describe my own code libraries this may help:
One general purpose library containing code that I expect all applications will have at least a 50/50 chance of needing to use. This includes string utilities, regexes, expression evaluation, XML parsing and ODBC support. Conceivably this should be split up a bit, but it makes distributing my code in FOSS projects easier to keep it monolithic.
A library supporting multi-threading, providing wrappers around threads, mutexes, semaphores etc.
One supporting SQLite via its native interface, rather than via ODBC.
A C++ web server wrapper round the Mongoose C web server.
The general purpose library is used in all the stuff I write, the others in more specialised circumstances. Headers for each library are held in separate directories, as are the library binaries themselves (though they should probably be in a single lib directory).
Make sure that the dependencies of your libraries form acyclic directed graph (a tree). While this is not necessarily a problem for static libs (I'm not sure in fact), it will be a problem if you ever decide to switch to dlls. Depending on your situation, this may require some redesign of interfaces.
Another thing I noticed (for sure on MSVC), which you may consider if build speed is an important concern: DLLs link much faster than static libraries. I assume this is because they don't have to be copied into the new executable and there's no need to search an eliminate unused code. Even if it's no option for production, you may use this trick while developing.
I also have the habit to create my solution files with CMake, because it is easier to overview the entire build process than clicking through an endless list of options in a GUI. It's up to you to decide if you want to walk that path.
We have a core library in the form of a DLL that is used by more than one client application. It has gotten somewhat bloated and some applications need only a tiny fraction of the functionality that this DLL provides. So now we're looking at dividing this behemoth into smaller components.
My question is this: Can anyone recommend a path to take to divide this bloated DLL into a set of modules that have some interdepencies but do not necessarily require all other modules?
Here are the options as I see them but I'm hoping someone can offer other possibilities:
Create a "core" dll and several "satellite" dlls which use the core and possibly other satellite DLLs.
Subdivide the contents of the bloated DLL into static libraries that the main DLL uses (to maintain the same functionality) but apps that don't want to use the bloated version can assemble the static libraries they need into their own dll or into the app itself.
I was hesitant to mention this but I think it may be important to note that the app uses MFC.
Thanks for your thoughts.
Somewhat related to your question is this question, about splitting up a very large C module into smaller ones.
How do you introduce unit testing into a large, legacy (C/C++) codebase?
It seems your question has to do with the larger question of breaking some large blob of code into a more modular system. The link above is definitely recommended reading.
Without having all the details it is a little hard to help but here is what I would do in your situation
provide both static and dll versions of whate3ver you release - for MT and single threaded.
try to glean from the disparate clients which items should be grouped together to provide reasonable segmentation - without having layers of dependencies.
having a "core" module sounds like a good idea - and make sure you don't have too many levels of dependencies - you might want to keep it simple.
You may find after the exercise that one big dll is actually reasonable.
Another consideration is that maintaining multiple DLLs and both static libs and DLLs will hugely increase the complexity of maintenance.
Are you going to be releasing them all at once every time, or are they going to be mix and match? Be careful here - and know that you could create testing issues
If no one is complaining about the size of the DLL then you might want to consider leaving it as is.