[yoklov]

The allocator support in C++11 and, from what I've seen, the proposed allocator support in C++1y/z/whatever still leaves a massive amount to be desired.

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.

[Paul_S]

There are no gamdevs on the c++ committee, probably because games companies are cheap bastards and don't want to expend resources on something that will affect them 10 years down the line (or even 2). Join the committee.

[yoklov]

Haha, even if that were something I was interested in at all, I'm honestly not sure what you could do to fix it at this point. I think that ship has sailed. Most of the issues are library issues (and are far deeper than my complaints about allocators). The language issues largely come from having too many features, and its not like any of them can be taken out.

FWIW, I'm currently pinning my hopes on JAI, even though it's a long shot.

[mrec]

What's "JAI"? I've never heard of it, and Google/Wikipedia aren't showing any plausible candidates.

[fulafel]

Jonathan Blow's language/compiler/live performance.

https://www.youtube.com/user/jblow888/playlists

See https://sites.google.com/site/jailanguageprimer/ for some fan-made notes from the videos

[mreiland]

I'm not a game developer, but I experienced something similar to that when playing around with SFML. Their texture objects adhere to RIAA, so copy constructors will copy the texture from GPU memory to main memory, copy it to another location in main memory, re-upload it to GPU memory, then destroy the original texture and the memory it took up when copying to main memory.

I asked about it and the response I got was basically "It's RIAA, that's how you do C++". The worst part is they have a caching system underneath that tracks OGL handles across different objects, and it's even safe for access by threads.

But whoever designed their texture class chose not to use it.

So when I read your description I understand where you're coming from a bit. I'm not sure I understand why you couldn't just avoid using destructors, but I've honestly never tried to use a C++ allocator for anything as I've never needed control quite that tight for anything I do.

[yoklov]

Well, you can avoid using desctructors, but then you can't use the majority of the STL, so what's the point? (This is basically what I do anyway)

[mreiland]

You don't have to tie resource lifetime to object lifetime, that's the mistake the SFML folks made.

[yoklov]

Right, my point is that I typically don't really want to tie memory lifetime to object lifetime either. So the whole of RAII is not a great fit, outside of a couple edge cases.

[mreiland]

RAII is about resources, not memory. If you don't want to tie memory lifetime to object lifetime then don't. That's the entire point of things like smart pointers.

That's exactly the issue SFML had. This idea that RAII implies tying resources directly to an objects lifetime. It doesn't.