• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Nairou

If developers hate Boost, what do they use?

35 posts in this topic

[quote name='Antheus' timestamp='1327966196' post='4907811']

You'll be hard pressed to get me to do anything in C++ without having boost, Qt or some other libraries as default.

Is something in these libraries interferring with my goals? Then they're out.


But the question shouldn't be whether to use boost or not. If should be whether OO-heavy ref-counted design is a good fit for problem being solved. Writing some UI and blob mangling app? It's fine. Writing HPC or real-time app? Throw it out. While you're at it, just use C.

There is no problem with libraries. They are fairly passive, boring and just tend to sit there. As for developers? Some are good, some are bad, some learn, some don't.
[/quote]

Some people paint a rosy picture about Boost. I tell people to "chew the meat and spit the bones." Some of the Boost libs are excellent and some not so much. I think highly of Boost.Insrusive and some of the other container libraries. The Serialization library though has a lot of weaknesses -- [url="http://webEbenezer.net/comparison.html"]http://webEbenezer.net/comparison.html[/url] .


Brian
Ebenezer Enterprises
[url="http://webEbenezer.net"]http://webEbenezer.net[/url]
-3

Share this post


Link to post
Share on other sites
[quote name='wood_brian' timestamp='1328037538' post='4908120']
The Serialization library though has a lot of weaknesses -- http://webEbenezer.net/comparison.html[/quote]
I don't mean to be rude here, but in all honesty you can hardly be considered to an objective source on this topic.

It's fairly well understood that boost::serialisation is not the best performing alternative, but I remain unconvinced that it's a bad solution. In particular, it's one of the very few solutions that works well with heavily templated code bases.
1

Share this post


Link to post
Share on other sites
Its less of a question about Boost and more along the lines of 'How do you choose what parts of the C++ language and libraries do you use'.

I've never met anyone that admitted to even using C++ iostreams, let alone liking them or using them for anything beyond stuff in an academic environment (i.e. homework).

STL and Boost pretty much require exception handling to be enabled. This is a dealbreaker for a lot of people, especially with codebases older than modern C++ codebases that are exception-safe. You are more or less forced to be 'C with Classes, type traits, and the STL/Boost templates and that don't allocate memory'.

RAII design more or less requires exception handling for anything useful, as you can't put any interesting code in the constructors without being able to unwind (i.e. two phase initialization is required). The cleanup-on-scope aspect is useful though without exception handling, since the destructors aren't supposed to throw anyway.

STL containers have poor to non-existant control over their memory management strategies. You can replace the 'allocator' for a container but it is near useless when the nodes linked list are forced to use the same allocator as the data they are pointing to, ruling out fixed size allocators for those objects etc. This is a lot of the motivation behind EASTL, having actual control, as the libraries are 'too generic'.

And memory management ties heavily into threading: We use Unreal Engine here which approaches the 'ridiulous' side of the spectrum on the amount of dynamic memory allocation it does at runtime. The best weapon to fight this (as we cannot redesign the engine) is to break up the memory management into lots of heaps and fixed size allocators, so that any given allocation is unlikely or not at all going to contend with a lock from other threads. Stack based allocators are also a big help, but are very not-C++-like.


My rule of thumb for using these libraries is if doesn't allocate memory, it is probably ok to use:

algorithms for std::sort is quite useful even without proper STL containers, and outperforms qsort by quite a lot due to being able to inline everything.
Type traits (either MS extensions, TR1, or Boost) can make your own templates quite a bit easier to write


I've also never seen the need for thread libraries, the code just isn't that interesting or difficult to write (and libraries tend to do things like making the stack size hard to set, or everyone uses the library in their own code and you end up with 22 thread pools and 400 threads etc)
2

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1328038928' post='4908129']
[quote name='wood_brian' timestamp='1328037538' post='4908120']
The Serialization library though has a lot of weaknesses -- [url="http://webEbenezer.net/comparison.html"]http://webEbenezer.net/comparison.html[/url][/quote]
I don't mean to be rude here, but in all honesty you can hardly be considered to an objective source on this topic.

It's fairly well understood that boost::serialisation is not the best performing alternative, but I remain unconvinced that it's a bad solution. In particular, it's one of the very few solutions that works well with heavily templated code bases.
[/quote]

Serialization in C++ is so painful I would say you should design the data structures to be as simple as possible, much like those that can be found in quake maps (X blocks of N kinds of binary data in simple structures that can be turned into trees etc easily at runtime).
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1328038928' post='4908129']
I don't mean to be rude here, but in all honesty you can hardly be considered to an objective source on this topic.
[/quote]
Feel free to dispute the results if you like. To the best of my knowledge the results are accurate.

[quote]
It's fairly well understood that boost::serialisation is not the best performing alternative, but I remain unconvinced that it's a bad solution.
[/quote]

I asked some time ago about whether the library would use move --
[url="http://boost.2283326.n4.nabble.com/Serialization-and-std-move-td2598382.html"]http://boost.2283326...-td2598382.html[/url]

The beta of Boost 1.49 is fresh off the presses and Boost hasn't improved in this area. This goes beyond performance to maintenance. Is there any plan to work on this in the future?


[quote]
In particular, it's one of the very few solutions that works well with heavily templated code bases.
[/quote]

I won't argue with that.
1

Share this post


Link to post
Share on other sites
[quote name='wood_brian' timestamp='1328078387' post='4908295']
[quote name='swiftcoder' timestamp='1328038928' post='4908129']
I don't mean to be rude here, but in all honesty you can hardly be considered to an objective source on this topic.
[/quote]
Feel free to dispute the results if you like. To the best of my knowledge the results are accurate.
[/quote]

<derail>
Why do your comparison programs return 1 from main? And why are they using C libraries (rather than the C++ versions (i.e. cstdlib and ctime))?

Additionally, you're comparisons are flawed. You should always have the program running for at least a full second before starting any timing measurements (this is to allow things to settle down and system start-up overheads to not interfere as much with the timing). You also don't provide hard numbers from the results, and I don't trust any timings that take less than a second (because it's so easy for the system to introduce a little slowdown here and there, adding noise to your timing results).

I'm not saying yours isn't faster or any one library is better than another; I'm just saying I question your benchmark programs, and from the code in the benchmark programs I question the library as a whole.
</derail>

I'll post something on-topic here: Boost is actually a nice asset. Of course it's not a panacea, but it does have various solutions for very common problems. Yes, in-house solutions may have already been developed for some of these problems, but that's not true for everyone. We use it at my work (in addition to several other libraries).

But I don't make games at work. If we were making games, I probably wouldn't get to use Boost (as others have said, it's template/macro magic is pretty heavy, and compilers for some gaming platforms might not be able to handle it). In addition, Boost does have bloated parts, true. But it's also a collection of libraries, so it's nice that you can take what's convenient to you and leave the rest. If there isn't something convenient to you, then you're free to use something else.

I think some of the "developers hate boost" mentality you're seeing stems from programmers who don't know what they're saying (kunos is a good example of this), who say things that make programmers around them shudder. I mean really, "exceptions are for pussies" (even if you were just joking) and saying that manual memory management is way easier than some kind of smart pointer (because it's harder to type shared_ptr<type> than delete)? (I'm not saying you HAVE to use smart pointers over manual memory management; I'm saying that your argument is silly; C++ is not necessarily a pretty language, and making eye candy your goal is the wrong approach (nor am I saying your code should be ugly... it's just... your goal should be to produce a quality, bug-free application that accomplishes the necessary tasks)).

[edit]

I sound really cynical/negative/condescending in this post. I apologize for that. I was just trying to write my impressions and that's how it came out; unfortunately it didn't come out more elegantly. It's past my bedtime though so I'm not going to stay up later to revise it.
2

Share this post


Link to post
Share on other sites
[quote name='kunos' timestamp='1327998678' post='4907923']
nightmares about circular references never cleaning up.
[/quote]

Use shared_ptr where the ownership of the object is [i]shared[/i], and weak_ptr for observers of an object and this should not be an issue.
1

Share this post


Link to post
Share on other sites
[quote name='wood_brian' timestamp='1328078387' post='4908295']
[quote]
In particular, it's one of the very few solutions that works well with heavily templated code bases.
[/quote]

I won't argue with that.
[/quote]
I would ask the question of why is your code base so heavily templated as the can add additional problems.
0

Share this post


Link to post
Share on other sites
[quote name='NightCreature83' timestamp='1328096705' post='4908344']
I would ask the question of why is your code base so heavily templated as the can add additional problems.[/quote]
Because almost the entirety of my code-base is written in a modern C++ style - i.e. functional programming and static duck typing via templates.

And I realise I may be a little pedantic on this point, but this is how C++ is meant to be written. If you want to use only OOP, go use a language that is designed for it (i.e. Objective-C).
1

Share this post


Link to post
Share on other sites
[quote name='Cornstalks' timestamp='1328080261' post='4908299']
<derail>
Why do your comparison programs return 1 from main? And why are they using C libraries (rather than the C++ versions (i.e. cstdlib and ctime))?
[/quote]
OK, I'm going to use those headers, but haven't rerun the tests yet.

[quote]
Additionally, you're comparisons are flawed. You should always have the program running for at least a full second before starting any timing measurements (this is to allow things to settle down and system start-up overheads to not interfere as much with the timing).
[/quote]

A few years ago James Kanze made some similar comments and I ran some tests based on his suggestions --
[url="http://groups.google.com/group/comp.lang.c++/browse_thread/thread/25b025a9d475ccad/5a0aec212581ddce?lnk=gst&q=o_largefile+wood#5a0aec212581ddce"]http://groups.google...a0aec212581ddce[/url] .

I'm of the opinion that the sort of test Kanze and you suggest is revealing/useful, but think it complements what I have on the web site. G-d willing, I'll run more tests like those in that link in the next week or so.


[quote]
You also don't provide hard numbers from the results, and I don't trust any timings that take less than a second (because it's so easy for the system to introduce a little slowdown here and there, adding noise to your timing results).
[/quote]

[url="http://quicklz.com"]http://quicklz.com[/url] --
Lasse doesn't provide the numbers either.

[quote]
I'm not saying yours isn't faster or any one library is better than another; I'm just saying I question your benchmark programs, and from the code in the benchmark programs I question the library as a whole.
</derail>
[/quote]

A lot more work goes into the library than the tests. Thanks for your comments. I've thought about revisiting some of those old tests and now likely will.
0

Share this post


Link to post
Share on other sites
[quote name='wood_brian' timestamp='1328121440' post='4908429']
[quote name='Cornstalks' timestamp='1328080261' post='4908299']
<derail>
Why do your comparison programs return 1 from main? And why are they using C libraries (rather than the C++ versions (i.e. cstdlib and ctime))?
[/quote]
OK, I'm going to use those headers, but haven't rerun the tests yet.
[/quote]
I didn't ask that question due to performance reasons, I asked it due to design and programming reasons. In C++, return 0 or return EXIT_SUCCESS (defined in cstdlib) indicates successful termination. return 1 doesn't really have much meaning (it may just happen to be the value of EXIT_SUCCESS or EXIT_FAILURE, but if it did that'd be coincidence), and from my perspective when I see return 1 I think "not returning 0, there must've been an error." Which hardly seems to be the case in your benchmarking app.

And I talked about the C libraries because... it's C++, not C. They're two different languages, and when someone pretends they're the same I start doubting that person.

Anyway, I'm done derailing this thread. Discussing this further would be done better through PMs or a new thread.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0