Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EA open sources their internal version of STL

github.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: EA open sources their internal version of STL

#31

Post by jparise »

jrockway wrote: post #4

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

Game companies generally use C++ because they need to interface with existing C and C++ library code (at least at the engine level). C++ also allows for various low-level optimizations when such things become necessary, such as resorting to inline assembler or stashing flag bits in pointers.

That's not to say that other languages aren't capable of these things, of course.

(I spent seven years working for EA, and I contributed to EASTL while I was there.)

Re: EA open sources their internal version of STL

#32

Post by jparise »

ukdm wrote: post #2

Source: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227... 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::…

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.

Re: EA open sources their internal version of STL

#33

Post by jparise »

jrockway wrote: post #24
aaronblohowiak wrote: post #20

Earlier quoted context omitted.

Right, they have a custom STL because they want to have their custom memory management.

Here's my experience. Whenever a C++ programmer uses the word performance, it's never to describe using template-based generic data structures. I do it and the performance is fine, but the hard-core C++ programmers seem to hate STL. Incidentally, I asked someone about memory management in an interview for a C++ position. He said he wrote his own memory manager (object pool, basically), and never even bothered to use…

EASTL is essentially the reaction of a bunch of hard-core C++ programmers who hated all of the other STL implementations.

Re: EA open sources their internal version of STL

#35

Post by DrJokepu »

ig1 wrote: post #8
jrockway wrote: post #4

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

A surprisingly large number of companies have their own STL implementations from Investment Banks to Telecoms companies. Often because they're doing funky things (often related to memory allocation) which would be outright impossible to do in languages like Java or C#.

Not trying to argue with you, I'd just like to mention as a curiosity that you would be surprised by how much 'funky' stuff you can do in C#. It has pointers (not just references, but real C-style pointers), it can pin objects in the memory, etc. It's hidden from the sight of the regular programmer, but it's there and it's part of the language, none the less.

Re: EA open sources their internal version of STL

#36

Post by jemfinch »

georgecmu wrote: post #19
archangel_one wrote: post #17

Earlier quoted context omitted.

I wouldn't call myself an expert on vertex buffers, but IIRC the OpenGL API to load data into a buffer just takes a pointer to the data and a size, so requires that your data is contiguous in memory beforehand - so deque may not have been an option.

Agreed. But I can't think of any data structure that would offer you contiguous, order-preserving storage and O(1) insertions/deletions of arbitrary elements.

There are actually implementations of deque which can store elements contiguously: imagine a vector where the "first element" is placed in the middle of the vector, and push_{front,back} reallocate whenever either end is reached. It wastes more memory than the typical deque implementation, but the elements are contiguous.

Re: EA open sources their internal version of STL

#37

Post by georgecmu »

jemfinch wrote: post #36
georgecmu wrote: post #19

Earlier quoted context omitted.

Agreed. But I can't think of any data structure that would offer you contiguous, order-preserving storage and O(1) insertions/deletions of arbitrary elements.

There are actually implementations of deque which can store elements contiguously: imagine a vector where the "first element" is placed in the middle of the vector, and push_{front,back} reallocate whenever either end is reached. It wastes more memory than the typical deque implementation, but the elements are contiguous.

You still don't get O(1) insertions/deletions of arbitrary elements with this implementation.

Insertions and deletions at either end are O(1), but inserting/deleting in the middle is costly.

Post reply on HN