Using Boost Libraries

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Thanks, I found those files and found out how to build the libraries.

      For the libraries there are a bunch of different builds. What is the single best build?

      If I go with mutlithreaded 32-bit static libraries for debug and release, that should be fine for any 32-bit app (including single-threaded apps) right?

      Do you know what the difference is between the debug and release builds?

      Should I add these to the property sheets for debug & release? When I added the MS DX SDK I found an article that said on the debug needs to be modified.

      Sorry for all the questions, most of this stuff is new to me.

      The post was edited 3 times, last by Roster ().

    • Hey Roster,

      When you say "multi-threaded 32-bit static libraries" are you referring to the "Runtime Library" option? I generally stick with Multi-threaded Debug DLL and Multi-threaded DLL for Debug and Release respectively. I've run into issues trying to use libraries statically, and I'm not sure if there's any real reason to link the runtime in in a static manner.

      If you're referring to your other libraries that you're including, then based on how GCC4 is set up, you'll want to link them in statically. Dynamic libraries add in a whole host of new complications that are just easier to avoid unless you need a dynamic library for some reason. One of the main issues is memory allocation: everything allocated on one side of the DLL boundary needs to be de-allocated there. Then there's the issue of what functions, classes, etc. that the DLL exports. As a rule, I'd say stay away from DLL's until you have a compelling reason to use them, as static linking is easier to understand.

      Difference between Debug and Release builds are just whatever settings the compiler and linker gets run with. You can create and name as many build targets as you want (Debug and Release being the default two Visual Studio gives you). By default, Debug has no optimizations turned on, and Release has full optimizations enabled. Obviously there are some more differences (such as whether debug information is included), but that will probably be your most noticeable one. You'll find that Debug is much easier to debug (go figure) because optimizations are turned off, so whatever code you have is what you're debugging. In Release mode, optimizations can make some fairly drastic changes, such as inlining functions, which could prevent you from stepping in to them, or might eliminate some or all of your debugging lines. For example, the "assert" statement just outright disappears in Release mode. I believe the same happens to GCC_WARNING and GCC_ASSERT, though I'd have to check. Long story short, you'll want to run Debug for most of your development, and then distribute Release (make sure to test Release as well, as there can be subtle differences that might cause issues).

      As for property sheets, I don't have much experience with them. Hopefully someone else (Rez) can list off some best practices :) I generally just fiddle with the individual project properties, though Visual Studio can be a little frustrating, so once I get Linux and iOS and other project types set up using make files, I might just do the same with Windows.

      Sorry for the wall of text, hopefully you can find something useful in there!

      James

    • Thanks, for the info. That makes sense. So, if I am going to distribute a game I would go with the Boost Release rather than Debug + the Release version of the game as well for the optimizations.

      I have only dealt with the Windows SDK and DirectX SDK before, and those only had one set of Includes and Libs from what I could see in the folders. I wasn't checking for that though.

    • I don't have a lot of experience with boost since most professional devs avoid it. In general, you want to link in the debug versions of your 3rd party libs with your debug build and the release versions with your release build. Never distribute the debug version of your game to end-users.

      I agree about statically linking libs. In general, you want to stick with statically linked libraries. Personally, I prefer to link in the multi-threaded static CRT libs as opposed to the DLL's, but that's a personal preference. And yes, the multi-threaded libs are the ones you want. They work just fine in single-threaded mode, there's just a bit of an overhead.

      It's hard to talk about best practices for things like build targets. Every company does it differently. On The Sims Medieval, we had Debug, DebugRelease, Release, and I think Final. We also had MSJIT and Mono versions of all those (for both PC and Mac). There were other random configurations too. Also, I think the game code and engine code could be on different targets, so you could be running the DebugRelease engine and the Debug gameplay code.

      On my own projects, I have four configurations. I have Debug, which is full dev mode. It's pretty much unchanged from the default VS setup and includes full errors, warnings, logs, and links all the debug libs. Then I have release, which is also mostly unchanged from the default. It has full optimizations and no logging, error messages, or asserts except for those at FATAL priority (reserved for catastrophic errors, like not being able to initialize the 3D hardware). I also have a Test build which is exactly like release in every way, except that all asserts, warnings, and errors are on. This is what content creators and QA run. They get full optimizations and get to see all the errors. This is as close to the end product as you can get without actually being the end product. This allows me to have a really nice, clean Release build and not incur the cost of logging errors and warnings the users will never see. My final build target is the profile build target, which is as close to release as possible while still allowing the debug introspection required by most profilers.

      Hope that helps.

      -Rez

    • shared_ptr.hpp is no longer necessary as all the boost smart pointers got pulled into the STL as part of C++11. Starting with VS2010 (or maybe sooner), you can just #include <memory> and then have access to std::shared_ptr, std::weak_ptr, and std::unique_ptr. This is how GCC4 does it now. A lot of boosts functionality is being built in to C++11. I'd suggest looking up whether any features you need are included or not, although being included in C++11 doesn't mean they're available in Visual Studio yet...but hopefully soon. If everything you need is already available in Visual Studio's implementation of the STL, then you can just cut boost out and make your build a bit easier :)

      James

    • We don't use boost at all in Game Coding Complete. It was used in the 3rd edition for smart pointers and multi-threading, but one of our goals was to remove it completely. We don't use it at all here on The Sims either.

      I don't use it in my personal projects either. I actually wrote my own smart pointer implementation to get around having to use anything from boost. ;)

      -Rez

    • We allow exactly one piece of C++ 11 here at EA. You are allowed to use the auto keyword in the case where you have to iterate through an STL data structure. That's it.

      Some people were using lambdas and the tech director sent an email telling us to stop. It doesn't work on Mac compilers, apparently.

      -Rez