Sean, can you comment on how, if at all, this relates to the Gaming and Low-Latency working group? I realize its early days, but I'm curious what early shape its taking and what sources the group is looking at and pulling from.
Well, I met Rob via SG14 at CppCon15 and we talked about EASTL a lot, so there's that.
Short version: the release of EASTL has little direct impact on SG14, but is a significantly useful tool to SG14's ultimate goals.
SG14 has grown really quickly and has a level of community involvement far beyond what I initially imagined. One of the things various contributors have been doing is looking at standard library improvements and changes that would be useful for games, embedded developers, etc. One of the first tasks we undertook was to review
Paul's original EASTL paper for WG21 that was presented back in 2007 and evaluate which bits had already been handled by C++11/14, which bits weren't super relevant to the common developer or modern hardware, and which bits were still key problems with the standard.
Various things one might find in EASTL are making their way into newer, small proposals. I'd suggest looking at the
SG14 Google Group to get a sense of all the amazing work people are doing, because I don't have my head wrapped around all of it.
An example was that I was looking into getting "flat containers" (think Boost's flat_map/flat_set/etc. or what EASTL calls vector_map/vector_set/etc.) into a real proposal for the C++ standard library. There's also working being done on other new containers, intrusive containers, math libraries, and a ton of other stuff.
(I'm likely going to be taking a back seat on that as I'm just far too busy this year getting our game out the door - my responsibilities on the project keep growing and my free time keeps shrinking - and my employer isn't sponsoring any time or travel expenses for unessential things like C++ community involvement.)
EASTL itself of course won't just become part of the standard, but a lot of the lessons of EASTL (where they different from the standard or typical standard implementations and most importantly _why_ they differ) is very important to the committee. EASTL being freely available is very helpful as most of us can't exactly share our core engine code with the committee for their education, after all. We need to educate the committee here, too: the standard is misguided if the third-largest industry using C++ by a huge margin (that's us! games are neat!) feels the need to completely replace the standard library at almost every single company, after all.
