Print

Please login or register.

1 Hour 1 Day 1 Week 1 Month Forever

Login with username, password and session length

[singalen]

Having found my C++ very rusty, I rationalized that it was not worth it in the first place. Turned to reading up on modern C++ and its downsides...
I found something worth attention -- EASTL - Electronic Arts' version of STL. The whole "Motivation" part is very interesting.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Motivation

[MaiZure]

These 'motivations' summarize issues that drove development of C++11. Going down the list, you'll find that just about all these weaknesses have been addressed in both 11, 14, and the working draft of the next standard (C++17?). Frankly, the STL wasn't great when this paper was written, but it has come a long way.

Other than the issues the EASTL folks said where in the draft of C++09 (which became C++11), I've found the following features really stood out over the past few years:

Smart pointers (that separate unique and shared pointers)
Lambda functions that can auto-type at compile time
Unordered associative containers and revamped iterators (covers a lot of the paper's complaints about container access).
A null pointer that isn't broken
...I guess I should plug RAII which seems to come up a lot in modern multiprocessing circles, although I don't have much experience in that at the application level.

Disclaimer: I'm not really a strong advocate of C++ for game development either...the resource management and plug-in algorithms feel like voodoo to me. But I do feel that progress does continue on the language to broaden it's appeal: Just ask the man himself (http://www.stroustrup.com/C++11FAQ.html). I suppose where the STL fails in games, there's always Boost (voodoo++)!

[Shadowfury333]

My understanding of the STL issues with games is a two-fold issue: STL classes are a mess of templates and virtual functions (which tends to introduce overhead), and STL containers are generally built to just work without sweating the details (which leads to inefficiently managed memory for objects)

The first issue is, as far as I can tell, endemic to any library trying to be general-purpose, but also something compilers can deal with. I don't know how much STL implementations use constexpr (new in C++14), but I wouldn't be surprised if they were trying to get as many function calls and template instantiations folded down to minimize overhead as possible, once the compiler is through with it.

The second issue, on the other hand, is indeed a design issue with STL. For applications that deal with large chunks of relatively unchanging data, they are fine. For applications that deal with data that's constantly changing in small chunks (like games) the overhead of constantly constructing and destroying objects, as well as the overhead when classes like vector<> need to expand, leaves a lot to be desired for performance. Linked list or map structures avoid that allocation issue, but have terrible cache performance, which is huge for optimization these days. On this, I don't know of any specific efforts to clean anything up, but I am aware of some research effort into containers that allow for dynamic allocation while minimizing destruction and allocation overhead, but nothing that seems likely to make it into STL for several years. Colonies are an example of this research.

There's also the whole SG14 working group, which is all about making standard C++ better for games development.

[singalen]

I see, thanks.
Poor me has to struggle with C++03, so I'm totally behind the modern C++ 8(

I heard, they can't get a proper type inference to work without traits, and these are not happening soon.

Wow, I thought that's the way std::vector is supposed to work from the beginning. At least, the insertion part.
Thanks a lot, that's enlightening!

[Shadowfury333]

Wow, I thought that's the way std::vector is supposed to work from the beginning. At least, the insertion part.
Thanks a lot, that's enlightening!

Wait, how did you expect vectors to work?

To clarify, on insertion, the vector first checks if free room has been allocated. If it has been, the new item is added. If not, the vector's internal array is reallocated with a larger capacity (in an implementation-dependent way), all the currently contained items are moved (rather than copied IIRC) to the newly allocated internal array, and then the new item is added to the vector.

The issue for games is more to do with deletion, rather than insertion, since deleting an item from a vector calls its destructor, and causes all items after the deleted one to be moved back, to keep the data contiguous. Given that objects in games are being deleted from containers all the time, and ordering generally doesn't matter, there's a lot of CPU time spent on operations that don't provide any value for the game.

[singalen]

I expected a good vector to allocate multiple segments, not a single one, like this colony does. Iterators are invalidated on modification anyway, so there's no point keeping the memory piece contiguous.

What's the difference between moving elements on reallocation and on deletion? The long-hyped move semantics should deal with both cases, no?

[Shadowfury333]

Move semantics does deal with both cases, so the performance cost of realloc/delete moves is probably negligible at gaming scales. The issue is more the cost of memory management and destructor operations on deletion, since frequent deletion and re-insertion is fairly common in games.

[Sereg]

For the time being, this thread is over my head, but as I'm trying to learn C#... I might ask some of you for help at some point =P

[thelaptop]

For the time being, this thread is over my head, but as I'm trying to learn C#... I might ask some of you for help at some point =P

You do realise that C# is nothing like C++ right?  It's closer to Java than C++ in terms of family and behaviour.

[Shadowfury333]

C# and C++ are two different beasts. However, they are also the exact two beasts I tame and ride every day at work.

[MaiZure]

For the time being, this thread is over my head, but as I'm trying to learn C#... I might ask some of you for help at some point =P

Stackoverflow is your friend

[singalen]

You're welcome to ask. I happen to know some C#, though it was in 2007.

[yaflhdztioxo]

It's closer to Java than C++ in terms of family and behaviour.

shhhhhhhh.

Those words.  We don't say those words out loud.
Those words upset the code monkeys.

[Kornel Kisielewicz]

Worth noting - JH uses a custom scratch built STL, much closer to EASTL, but based on the C++17 standard documents.

[singalen]

Indeed.
Hope you don't spend too much time reinventing STL. After all, they still develop EASTL, not sure if in C++17.
People have already reinvented/augmented STL a couple of times.
Got links here.