General > Off Topic

C++ and STL. How portable is JH?

(1/3) > >>

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:

--- Quote from: singalen on December 16, 2016, 12:44 ---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!

--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page