

EA open sources their internal version of STL - seekely
http://github.com/paulhodge/EASTL

======
ukdm
Source: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2007/n227...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html)

Differences between std STL and EASTL

First, EASTL provides a set of containers, iterators, and algorithms that are
identical in interface and behavior to std STL versions with one exception:
allocators. EASTL has a different allocator specification which is simpler,
more efficient, more flexible, and easier to use than std::allocator. Both
std::allocator and eastl::allocator are described below. EASTL follows the
defect reports and TR1 as well. EASTL additionally provides and uses some of
the TR1 functionality as well, including most significantly the smart
pointers, type traits, and hashing containers.

Second, EASTL provides extension functionality to the above containers,
iterators, and algorithms. An example of this is the push_back(void),
set_capacity(size), and validate() functions added to eastl::vector. The
majority of these extensions are driven by the need for higher performance
(push_back(void)), higher clarity (set_capacity), or higher debuggability
(validate()). There are about 30 such extensions to the various entities in
the library. These are described in detail below.

Third, EASTL provides additional containers and algorithms that don't
correspond to std STL. These include intrusive_list, vector_map,
fixed_hash_set, slist, ring_buffer, radix_sort, has_trivial_relocate, and
others. These are described in detail below.

There are additional differences not related to the functional specification.
They include a programming philosophy that emphasizes readability,
consistency, and optimal performance on limited hardware.

~~~
jparise
Other nice additions are the fixed-sized containers (fixed_vector<> and
friends) and the somewhat-enhanced string<> class (which adds things like
sprintf() support).

I've missed all of these things greatly since leaving EA.

------
jrockway
This is why game companies use C++. They've already reimplemented it
internally and don't ever want to do that again.

~~~
terryjsmith
I imagine most STL classes still don't fit game programming paradigms. My very
first experience with this was using vectors to store vertices as an
intermediary before sticking them into a vertex buffer. Granted, my math was
awful, but the memory overhead was absurd. I constantly find myself over using
STL in my programs because of how easy it is, then redoing it to use standard
C/C++ arrays, linked lists, etc. for efficiency.

Ranting aside, I'm most curious to look at any optimizations they've made.

~~~
archangel_one
Any sane implementation of std::vector is probably going to have three
pointers of overhead, and might allocate twice as much memory as required in
the worst case when you push a bunch of objects into it. That doesn't seem
totally absurd to me - was yours much worse, or am I just being more tolerant
of it?

~~~
NickPollard
You're being more tolerant. When you're building a high performance game
engine for fixed target hardware, the last thing you want is to be doubling up
the size of your arrays.

~~~
albertzeyer
If you know before the allocation how much entries it must hold at maximum,
you can give an std::vector that information. There is simply no case where
you are forced to require more memory with an std::vector but not with a
manual implementation.

~~~
repsilat
If you have a lot of small vectors those three pointers can be expensive. On a
64 bit machine they're 8 bytes apiece.

If you know the vector isn't going to be enormous you can swap two of those
pointers for unsigned integers, cutting overhead down to 16 bytes total. If
you know more about your data and usage patterns you can probably get it
further. For very small vectors of largely static data you might trade one of
the integers for linear-time insertion and deletion. If capacity is known at
compile-time you can make it part of the type. If you know that size() will
always equal capacity() you can get rid of the size int.

It's also worth noting that you don't have to double your storage on every
reallocation to avoid linear-time insertions - you just have to multiply it by
some constant that's greater than one. If you don't know how many reallocs
you're going to do, but you know that it isn't many, you might want to just
multiply your capacity by 1.1 every time to avoid a lot of wasted space.
Assuming, of course, that you're happy with bringing floating point
computation in, and that you've thought about how you're going to increase the
capacity of a vector of size 1...

------
Keyframe
<http://news.ycombinator.com/item?id=1798215> \- barrybe set up that github.

Here are first rough benchmarks: <http://msinilo.pl/blog/?p=668>

------
bhickey
Why the heck are they hosting it at <http://gpl.ea.com> when they've released
the code under the 3-clause BSD license?

------
w1ntermute
What's their reason for open sourcing it?

~~~
pkaler
They ported WebKit to the PS3 and Xbox 360. EA STL was used for this port.
More code here:

<http://gpl.ea.com/>

------
axus
E. A. STL. It's in the game.

But don't say it like that, it's against the license ;p

