Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

I give you the C++ standardization committee. Someone submits a paper to them with their issues and, moreover with solutions fully implemented in a library and also details the whys and wherefores. I have nothing to say whether this was good, bad or middling work just that the C++ standardization committee "has no record" of actually having read and considered it 8 years later and the chairs don't recall doing so. But I'm sure they all ran around as "anointed smart people" claiming all the others on the committee are anointed smart people instead. Sorry if I'm sounding a bit bitter but they really need to be called out, this is really gross. It's contemptuous of people making the effort to make the language better is the best you can say of it. Arrogant, stupid, unkind, vicious and bitter might describe me and I am sorry for it if you feel that way (please note it and I will try to do better), but I think it's also a fair description of this act by the committee.

Also on the front page today was Bruce Eckel's "thoughts on scala" which were utterly ridiculous for the first 10 minutes I watched. -He's a C++ stanardization committee alumni.

"We feel that a holistic "here's a new STL and our problems" approach to any change seems a bit doomed. "

WTF? You can't learn anything about what changes are desirable in the language from the implementation of how they solved their problems and assess whether they are more generally applicable? Pieces of them aren't worth assessing to be just adopted (or rejected)? You can't criticise what they tried and note the implementation and why the STL can do better?

Seriously if you can't learn anything from this on the committee what the hell are you doing? Well NOW they are looking at it, hurrah! While justifying why it wasn't done before, boo!

Mea culpa and a rocket up the committee members of the time seems vastly more appropriate if you actually care about this language. (Obviously if you don't, resign from the committee, immediately, anything else is immoral) If the members didn't care then, highlight the fact and state it is unacceptable going forward.

If it's common or garden (hopefully isolated) incompetence like all of us display at times. "We're very sorry this happened." Would seem to be about the minimum standard here. It's the arrogance that goes along with the committee when they act like this that really gets me.

If I have to build one more system that requires either a custom parser or repeating the names of all members, I think I will cry. The compiler ALREADY KNOWS!

Polymorphic allocators solve what's basically a non-problem for games (ABI boundary problems) while introducing huge other issues. Alignment is a PITA but not really a pressing IMO. The real issue is stuff like rebind and the requirements to call destructors (which destroys many practical implementations of pools and arenas, respectively). This probably falls under "STL puts an emphasis on correctness before practicality and performance".

...

Honestly (and I am aware this isn't a popular opinion, although it's much more popular inside the game industry than outside of it), IMO the STL-style of C++ programming is fairly wrong for games in general, largely because of memory usage concerns. This style of programming emphasizes worrying about lifetimes of objects by way of RAII, in order to allow a uniform way of treating all types of resources, both memory and otherwise.

This is convenient, but games need extremely tight control over non-memory resource management (need to reuse anything from the system, need to load lots of stuff in the background, etc). This means tying it to object and scope lifetime tends to be inflexible and cause future pain when you need to change the resource management scheme.

And for memory, games tend not to care a lot about cleaning up each objects memory individually, preferring to do it in bulk (e.g. resetting an arena or pool). This means that using RAII (or using something that uses RAII) for memory management tends to fit poorly for games.

So, IDK. I'm not holding my breath on the C++ standards committee making a decision that I care for, but it looks like they're making steps in the right direction nonetheless.

While gaming does drive innovation and it's a very interesting field, I doubt that's what most software people are working on and surely it's not the biggest sector of software industry in general, it's actually quite small in comparison with many others. That's not to undermine its value, just pointing out the broader perspective.