I've been using Boost for quite some time now. For developing cross-platform code, it has been a huge help in reducing the need for platform-specific code. However, it comes with its own baggage, in terms of library size, slower compile times, and cryptic compiler errors.
In talking to game developers in other studios (AAA and indie), I've started to get the almost-universal impression that they hate Boost and wouldn't touch it for any serious (non-tool) development.
I can somewhat understand this, and I myself have been trying to reduce my use of Boost in order get a grip on compile and debug times, but there are some pieces of Boost that have been too useful to give up. For example, the threading library. Without it, I would have to write platform-specific code every time I created a new thread. Or the filesystem library, which lets me query files and directories without dealing with path separator differences and such.
So if most developers hate Boost, what do they use? Are they really just writing lots of platform-specific code for each game? Or are there lighter alternatives out there that work just as well for specific tasks?
If developers hate Boost, what do they use?
In addition to the fact that Boost isn't a single library (it's a collection of quite a few libraries), I'd say the attitude in most games studios isn't "hate" as much as "know we can't actually use it."
Boost libraries often rely heavily on template tricks, for instance, which may not work well on the compilers that are available for certain console platforms. There's also a tendency in Boost code to rely on certain performance characteristics that are true of mainstream desktop/notebook CPUs, but not necessarily valid on mobile or console processors. (Cache behavior is a big deal on a lot of those CPUs, for instance, whereas PCs just continue to get better caches.)
The reality (for me at least) is that I'd love to use Boost in a few places, but it just doesn't hack it. There's also places where it's a fine prototyping solution (e.g. asio) but really heavy-duty applications need special-purpose designs to begin with.
Boost libraries often rely heavily on template tricks, for instance, which may not work well on the compilers that are available for certain console platforms. There's also a tendency in Boost code to rely on certain performance characteristics that are true of mainstream desktop/notebook CPUs, but not necessarily valid on mobile or console processors. (Cache behavior is a big deal on a lot of those CPUs, for instance, whereas PCs just continue to get better caches.)
The reality (for me at least) is that I'd love to use Boost in a few places, but it just doesn't hack it. There's also places where it's a fine prototyping solution (e.g. asio) but really heavy-duty applications need special-purpose designs to begin with.
Usually we come up with low-level cross-platform implementations with a C-like interface, and then we wrap those with higher-level classes.
Also for an STL replacement, at my last job we used RDESTL.
Again, making your own wrapper for these APIs is only a few hours work.
For example, the threading library. Without it, I would have to write platform-specific code every time I created a new thread.
Usually we come up with low-level cross-platform implementations with a C-like interface, and then we wrap those with higher-level classes.^QFE -- wrapping up the OS's native threading API in your own cross-platform wrapper shouldn't be more than a few hours work.
Or the filesystem library, which lets me query files and directories without dealing with path separator differences and such.Most games don't use the filesystem very much. Also, native OS file-system APIs usually provide ways of using them that the usual cross-platform wrappers don't allow for, such as mapping a HDD file to a RAM address, so you can read the file using a pointer, as if it were already in RAM. Or, on Windows, when I use the CreateFile/ReadFileEx API, I can load huge data files using the OS's built-in background loading system and take advantage of the OS's file-caching abilities, which allows me to load multiple-GiB files in less than 33ms and without stalling.
Again, making your own wrapper for these APIs is only a few hours work.
I don't use boost a lot, however quite often I am looking into its source as a background for my projects.
In general boost is very nice package, but sometimes its libs are useless. For example uBlas is completly useless comparing to BLAS and LAPACK therefore I would never use it in a real HPC project. But on the other hand Boost MPI graphs are really worth checking.
In general boost is very nice package, but sometimes its libs are useless. For example uBlas is completly useless comparing to BLAS and LAPACK therefore I would never use it in a real HPC project. But on the other hand Boost MPI graphs are really worth checking.
Even standard STL (the one shipped with the compiler) is avoided in most places for the same reasons as boost, and often replaced by in house STL, EASTL or STL port.
I wrote my own abstraction layer for my applications and it wasn't a big thing. The basic thread handling in windows and in linux isn't this much different.
The STL is used because of its simple usage. If I identify something for optimization it gets replaced with problem specific code.
The STL is used because of its simple usage. If I identify something for optimization it gets replaced with problem specific code.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
