Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

102 Neutral

About gg405

  • Rank
  1. As this is a religious debate in many cases, I would direct the OP to do his own research. Here are some links to get started: "Advantages of Using DLL's" - straight from the Horse's mouth: http://msdn.microsoft.com/en-us/library/dtba4t8b.aspx Read this page carefully and consider how many of the "advantages" actually are true in practice, or apply to you at all. These may be not very in-depth, but if you read the comments they all make the same basic point. The only time it is beneficial to break code into deployment packages if you really intend to share that code among applications. http://stackoverflow.com/questions/2881296/one-big-executable-or-many-small-dlls http://stackoverflow.com/questions/1592644/which-is-better-one-dll-for-all-or-many-dlls http://forums.asp.net/t/461506.aspx/1 http://www.codeproject.com/Questions/259523/Multiple-DLLs-Vs-Single-DLL I got these by googleing "one dll vs many" or similar strings. I did not cherry pick, but you'll see in most cases the answer is the same. One DLL unless you have a good reason. In the end, this decision, like all programming, comes down to trade-offs. Know what it is you're trying to do, evaluate the benefits and costs in light of your goals, and then make an educated guess. Don't spend too long on it, because it's holding up your development efforts. ;)
  2. It seems we could get into a very heated religious debate on this topic, and I don't really see the point in simply rehashing all the written material already on the web, but I'll try to focus my response: Simply using a DLL instead of a static lib won't cause problems. [/quote] Simply using a static lib instead of a DLL won't prevent bad programming practice, which seemed to be what the first 2 posters implied. Your response, on the other hand, seems to revolve mainly around improving link times. This statement: If the devs of chrome had all of their code in a single dll, a single change would take hours to re-link! [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][/quote][/font] Seems to me to be just blatantly false. The application I work on is significantly larger than Chrome (total size of our DLLs is 746 megs (debug), so guesstimate half for release. total size of "chrome.dll" is 28 megs). I can build my entire project from scratch, including compile and link time, in about 20 minutes. Why would you think it would take "hours" to re-link such a small DLL? EDIT: [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]Also, visual studio does incremental linking to speed up the process by default in debug builds anyway, so you're probably not re-linking the whole thing... [/font]
  3. Also, sorry to spam, but if you're thinking about using DLLs anyway, and you need to pass stuff across DLLs or across processes, you can start here: http://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.80).aspx I had a case where I needed a static variable inside a class in a DLL (it was used to prevent dialog re-entrancy). Unfortunately, this DLL was being used by two different apps (a desktop app and also a browser plugin), so they were two totally separate memory spaces, so two different static variables. The only way to fix this was to use solutions from the above. Really kludgy. Hate it. But again, this was because I had *multiple processes* that needed to run the same code at the same time, so it actually was the right solution (short of using some kind of OS-based semaphore). Most games (or apps in general) don't operate like this, and aren't well served by the additional complexity.
  4. The biggest purpose for DLLs (or "shared libraries") is when you plan to share your library (go figure) among multiple applications/processes, not multiple developers. Don't confuse something designed to improve programmer efficiency (the use of OOD, well-defined interfaces, code reviews, etc.), with something that was originally designed to address distribution and support of multple programs that want to use the same shared code (VC runtimes are a great example). What is being discussed here is really two different beasties. First Important Point: Whether you have 1 mammoth DLL or 270 tiny DLLs (like the app I am Lead Dev for does) has nothing to do with the fact that the right way to program large apps is to come up with solid, generic interfaces and code to them. This makes your code more modular, more reusable, and allows you to put more people on the project without breaking each other on a daily basis. This is one of the fundamentals of OOP, and has nothing to do with how you link your stuff. You isolate programmers by having them change encapsulated implementation details. No one cares if the code they are writing ends up in a static library, a dynamic library that gets linked into a DLL, or how many DLLs there are. What they WILL care about is that you had a call yesterday that took 3 parameters, and today it takes 4, and they have to change their code in 150 places. DLL's don't touch this issue at all, for good or bad. The way to enforce proper programming approaches is through solid interface design, and code reviews to make sure people are sticking to it. Second Important Point: There are many, many, many problems with DLLs, and many complicated systems have been invented to try and resolve them (start your learning journey with the search phrases "Windows COM", and "DLL hell"), and the problems just keep getting more and more complex as the solutions do. Deciding whether you want a bunch of DLLs is really an easy ask: would you rather manage 4 files to distribute, or 400? DLL's serve a purpose, but most of those purposes remain down lower than you need to worry about. VC runtimes make great DLL's. OS code makes great DLL's. Things that a LOT of apps need access to, and need frequent updates - THESE make great DLLs. Now, let's say you're building a game engine. Unless you plan to a) use that engine in several games; and b) want to be able to update the engine with application X and allow application Y to benefit from the improvements - then you don't need a DLL. In fact, it can cause a lot of problems if you TRY to share a DLL between two different apps like this, when they end up being incompatible (see "DLL hell", referenced above). In general, what really happens is you have version 1 of an engine that you ship with App X. Then when you make App Y, you improve the engine, and ship Engine version 2 with App Y, and so on. If you now try to run App X and it loads Engine 2, well, unless you're World-Class good at forward-design (also known as "psychic", "lucky", or "liar") - then you will have not anticipated something. Then you've either got multiple versions of the same interface all doing different things, or some other kludge - but all to the same effect: different engine code for different apps. Current best practice is to create a small bootstrapper exe, and then gob as much stuff as makes sense into a single DLL. For a great example of this, see Google Chrome. They have a few DLLs, but most of their code ships in one (relatively) large chrome.dll. I've come down pretty hard on DLLs, so I'll try to advocate for them at least a little. A great use for DLL's is if you are creating something that you want to sell to someone else, like an SDK. Then, you package your stuff up in a DLL, give them the header files and (hopefully) expanded documentation, and then they can use your code without having access to it, so you can retain the IP.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!