Jump to content
Posted 18 January 2012 - 02:42 PM
Posted 18 January 2012 - 03:16 PM
Posted 18 January 2012 - 05:16 PM
Posted 18 January 2012 - 05:22 PM
For example, the threading library. Without it, I would have to write platform-specific code every time I created a new thread.
^QFE -- wrapping up the OS's native threading API in your own cross-platform wrapper shouldn't be more than a few hours work.
Usually we come up with low-level cross-platform implementations with a C-like interface, and then we wrap those with higher-level classes.
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.
Or the filesystem library, which lets me query files and directories without dealing with path separator differences and such.
Posted 19 January 2012 - 12:27 AM
Posted 19 January 2012 - 02:44 AM
Posted 19 January 2012 - 03:41 AM
Posted 19 January 2012 - 11:26 AM
Posted 19 January 2012 - 12:39 PM
Posted 19 January 2012 - 01:56 PM
Two relevant points:
However, people who aren't using boost, do you use shared_ptr? -- because I think I draw the line in the sand there. At this point, haven't written the keyword "delete" in a couple of years and am not interested in going back.
Posted 19 January 2012 - 02:28 PM
Also, on embedded there's a good chance you won't be able to afford to manage memory in such a haphazard fashion. As someone mentioned earlier, embedded devices don't have the kind of general-purpose caches that PCs do - you'll often have to massage your data to eek every little bit of cache coherency, and that tends to put paid to traditional C++ memory management...
Posted 19 January 2012 - 02:36 PM
What use is a smart pointer, if you are going to have to give up dynamic allocation entirely? Writing for the kind of resource constraints you face on a lot of embedded hardware is a whole other ballgame...
Couldn't you use the intrusive version of shared_ptr in this kind of situation?
Posted 30 January 2012 - 04:59 PM
Posted 30 January 2012 - 05:18 PM
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.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
ScapeCode - Blog | SlimDX
Posted 30 January 2012 - 05:24 PM
First of all I have never used Boost. A little over a year ago I bought bjarne stroustrup's "the c++ programming language". I have learned a great deal about proper OO design since stroustrup spends a lot of time talking about design philosophy behind c++. I would be curious to know how well Boost follows this design philosophy?
One design goal of c++ is to give the required tools to build powerful and extensive libraries. But often a library is built to go from point A to point D and fails to implement the B and C features properly b/c it's so obsessed with getting to D.
Also in regards to the discussion about smart and shared_ptr, stroustrup devoted a section talking how to implement this ground up from the std lib. It's extremely useful but when I see people say to use a 3rd party lib to implement a feature this simple I think there a lack of understanding there.
My experience has been that most commonly needed features are easily built on-top of the std lib (for this is what the std lib was designed for).
Heck I even designed my own GC that is remarkably efficient and stable. All the parts to roll your own GC is there you just have to put them together.
You will never learn how to do this if you use 3rd party libs all the time.
Posted 30 January 2012 - 05:29 PM
Thus when these programmers go on to actually become industry professionals and start doing development work... guess what? Yeah.
Posted 31 January 2012 - 02:31 AM
At this point, haven't written the keyword "delete" in a couple of years and am not interested in going back.