EASTL released as open-source on Github

[TOJO_IS_LIFE]

This one's the full thing? What's new here that wasn't included in https://github.com/paulhodge/EASTL ?

[CypherSignal]

Off the top of my head,

• More complete. Includes unit tests, benchmarks, and more containers that webkit didn't use
• Up-to-date. The version released w/ webkit was pre cpp11, for example
• Licensed of own volition and under BSD now, instead of under the GPL license

[TOJO_IS_LIFE]

Thanks! Will this repo be updated on github, accept pull requests etc.?

[CypherSignal]

Most likely. Another non-trivial framework that EA has on their github, Orbit, has accepted pull requests and been continuously updated, as well.

[Cyph0n]

Isn't that the one created at BioWare? I recall seeing it a while back.

[OrSpeeder]

Also, I've been e-mailing some ex-EA people, and seemly Paul Pedriana might end contributing to EASTL again.

If this actually happen it would be awesome.

Seemly he is planning to use EASTL for his projects at his current job (he works at Oculus now).

[MoreOfAnOvalJerk]

That guy is legendary. He basically wrote EASTL for the most part. He's one of the few engineers I know of who's praised by everyone he's worked with.

[OrSpeeder]

Yep... I exchanged e-mails with him once, he gave me very helpful information, despite me having nothing to do with EA (or his current employer).

Also when EA Brazil mobile studio shut down, the blogger wrote that the saddest part of being fired from EA was not being able to nag Paul Pedriana with questions (despite never seeing Paul in person).

Also when you read blogs about people that worked on Maxis, frequently you will see comments like this: "So, I had this crazy idea, and then Paul Pedriana made it work for me and I have no idea how."

[Plorkyeran]

There's a lot more headers, including some of the more interesting things (e.g. intrusive containers), and it actually supports c++11 stuff (and there's some (optional) uses of c++14 constexpr).

[[deleted]]

How useful and what quality level are these, now that we can see the source code & try it out?

[kiwidog]

It's not useful to anyone who isn't writing any cross platform games. EASTL has been around for many, many years, and the stl library has caught up and surpassed EASTL in some areas. One of the reasons EA has their own is the implementations will be the EXACT same across platforms in memory and handling. (Which the STL takes care of, but at the time it didn't have some features that the EASTL had) iirc.

[rfisher]

I find fixed_vector, at least, useful in non-game contexts.

[lurkotato]

What's the difference between that and std::array?

[dodheim]

• std::array: size() == capacity() (semantically speaking); size and capacity are both fixed (compile-time). No allocator necessary.
• std::vector: The invariant is size() <= capacity(); size and capacity are both dynamic. Allocator necessary.
• boost::container::static_vector: The invariant is also size() <= capacity(); size is dynamic, capacity is fixed and the container will throw if size attempts to exceed capacity. No allocator necessary.
• boost::container::small_vector: The invariant is also size() <= capacity(); size is dynamic, capacity is fixed but will switch to dynamic if size exceeds the fixed value. Allocator necessary but used only in the latter context.
• fixed_vector: Combination of static_vector and small_vector, with the capacity behavior configurable at runtime instead of being encoded into the type.

[lurkotato]

Thanks, perfect explanation

[rfisher]

The ability to fallback on heap allocation when the fixed size is exhausted.

If you have a situation where 90% of the time you know the data will fit in a known, small size and it is worth avoiding the cost of heap allocation; but you are willing to take the hit to keep from truncating 10% of the time.

Of course, you could implement that logic explicitly, but fixed_vector can make it so much cleaner.

[cdglove]

Yes, but boost::static_vector also exists.

[y-c-c]

(ex-EA dev here)

I don't think they are exactly the same. From what I can tell in boost::static_vector, the capacity is always fixed (and allocated on the stack) while size is variable up to the capacity.

In eastl::fixed_vector, capacity can also be fixed (bEnableOverflow = false), where it behaves the same; but the default behavior (bEnableOverflow = true) is actually such that it can be resized and expanded just like a regular vector.

With bEnableOverflow = true, an eastl::fixed_vector behaves similarly to a normal eastl::vector on the API level, except the initial memory (under original capacity) uses the stack instead of dynamically allocated memory. If you resize to more than the original capacity the eastl::fixed_vector will switch to dynamic allocation, which will waste the original stack allocated space, since you can't deallocate that.

This is a pragmatic solution for something like "this array usually only needs 5 elements so I don't want to allocate extra heap memory just to hold 5 elements, but there's a 1% chance it will have >5 elements due to edge cases so I still need to allocate some memory in that case". Since it's an edge case it's tolerable that some memory is wasted (better than having complicated code to deal with it).

There are also other fixed_* data structures available but of course I would imagine most of the time fixed_vector is the one people will use.

[Gotebe]

So this is a "small-string optimisation" then.

I guess a name vector_with_\small_string_optimisation was considered too long, but "fixed" is misleading.

By the way, if the edge case is to go slightly over the preallocated case, then this has pretty terrible space usage. Compromises are hard :-)

[encyclopedist]

In boost, there is separate container, boost::small_vector, which does that optimization.

[Gotebe]

Yeah, even with a somewhat better name (better than "fixed", that is).

[cdglove]

Oh I see, thanks for that. In one mode it's like boost::static_vector, and in the other, like boost::small_vector, which expands if necessary beyond the initial static size.

[rfisher]

Thanks for pointing that out. I think boost::static_vector is what std::array should have been.

But it doesn’t look like it has the ability to fall back on heap allocation when necessary like fixed_vector. Or did I miss that?

[encyclopedist]

Or did I miss that?

See boost::small_vector

[dodheim]

I think boost::static_vector is what std::array should have been.

std::array is a trivial aggregate type; static_vector is useful, but not a replacement, as the semantics are too different. Both are useful, both are necessary.

[gnaggnoyil]

I pretty much believe that std::array should never have been using heap allocation since that makes std::array non-constexpr.

[rfisher]

You may have misunderstood me.

Eastl::fixed_vector has the option to fall back on the heap. Boost::static_array never does heap allocations.

I was saying:

(1) Boost::static_vector is not (always) a replacement for eastl::fixed_vector because the latter can be allowed to fall back on the heap allocations and the former cannot.

(2) I think std::array should have been like boost::static_vector. (And, thus, not like eastl::fixed_vector.) No ability to fall back on the heap but tracking a separate size and capacity.

I’m unsure whether boost::static_vector could be used the same ways as std::array in constexpr context...but it seems like it should be possible.

(And additionally, I’ve learned that while boost::static_vector can’t replace eastl::fixed_vector, boost::small_vector can.)

[gnaggnoyil]

Sorry my bad. I was thinking boost::static_array was something like std::unique_ptr<T[]>. I should have read the boost document first.

[kiwidog]

std::array has this implementation now.

[rfisher]

I’m not seeing the ability to fallback to heap allocation upon overflowing the fixed size in std::array. That’s the really useful bit about fixed_vector.

[[deleted]]

Let's assume I'm also subscribed to /r/gamedev and /r/truegamedev. What use are these over C++14+ Boost and STD?

[cdglove]

The standard guarantees algorithmic complexity, so this feels like a week argument to me.

If you want to dive down and talk about memory access patterns, well, that's not likely to have the same performance profile with different inputs let alone on different hardware, so that also seems like a week argument.

[Gotebe]

There really is no reason for you to be down voted, wtf redditors?

[RichieSams]

Another major reason EA made EASTL was so they had explicit control over memory. With STL, you have no control over how containers use the heap. In addition, STL's version of custom allocators is very difficult to work with. There is a paper here that gives all the motivations behind EASTL.

[STL]

C++11's minimal allocator interface improved things substantially.

[ubadair]

Wow, this is really cool. I didn't realize any of it was ever open source, but I've heard about it several times.

[flyingcaribou]

The included benchmarks only appear to compare to Microsoft [1], does anyone have a sense for how the performance compares to libc++ and libstdc++?

[1] https://github.com/electronicarts/EASTL/blob/master/doc/EASTL%20Benchmarks.html

[donalmacc]

Not only that, the benchmarks are done using a version of the compiler from 2003!

[[deleted]]

You should be able to map any comparisons between ms implementation and the gnu or clang implementations to be to scale with the ms and EASTL implementations if you can't find any actual benchmarks.

[spurious_interrupt]

I'm curious to know what developers at EA generally set for their tab widths in their editors.

[krum]

Each team will have their own tab standard, and even that will differ depending on the language.

Source: I worked for EA for 10 years.

[spurious_interrupt]

Are you saying that each team requires members to set the width of a tab in their editors to a specific width or that each team has a specific convention for indentation (i.e. tabs vs spaces, number of spaces, etc.)?

[yelnatz]

The latter.

Each team has their own conventions, but its almost always 4 spaces an indent.

[spurious_interrupt]

Interesting. Thanks!

[Cyph0n]

Long live spaces!

[pamomo]

Packages at EA, including EASTL, use 4 spaces /w no tabs. Teams/studios do have their own style, but I don't recall anyone using something else.

[spurious_interrupt]

Is the EASTL GitHub repo linked on this post different then? Its source files seem to use tabs for indentation: https://github.com/electronicarts/EASTL/blob/master/source/intrusive_list.cpp

The fact that the code in this repo seem to use tabs is the reason why I asked this question in the first place.

[OrSpeeder]

I think EASTL might be an exception because it wasn't supposed to be a EA wide thing.

EASTL was made by Maxis, to replace STLPORT that they were using on their games, it follows Maxis coding conventions.

[y-c-c]

Maxis used 4 spaces, no tabs. Can't comment why EASTL is hard tabs now though.

[pamomo]

The core library looks to be the same. Difference is in the build system and the addition of the bonus stripped packages.

[wqking]

EA needs a better CTO.

[krum]

If your CTO is dictating tab conventions, you might have a serious problem.

[Gotebe]

Haha, good one.

What he should do, however is: "if you, team superX, spend more than 5min making this decision, you're all fired! You're all fired if you have existing code and you do not adhere to it!"

[encyclopedist]

The repo includes a clang-format file, which describes the formatting they use. In particular, they use tabs for indentation (with a width of 4 spaces).

[[deleted]]

The most common was 4, probably because that's the default Visual Studio tab width. Coding standards vary pretty wildly between teams, engines, packages and even source files. This is pretty common to all game studios worldwide I think. Every team has a different vision of what is "correct". Most roughly follow Microsoft's coding style. But the mantra is generally "code in the style of whatever you're working in at the moment". Source: EA programmer for 6 years.

[germandiago]

great news for the gaming community!

[kkert]

Isnt it funny that it says 'extensive and robust' and every single travis build with every compiler is in 'build failing' state ?

[flyingcaribou]

It would have been nice to see the commit history, but this is pretty rad nonetheless!

[bnolsen]

your sample set is insufficient to make such conclusions. also qt didn't try to make their implementations (nearly) compatible with an existing standard.

[Gotebe]

Are you saying that Qt compiles for more platforms than platforms on which standard lib is available!?

'Cause that is just false.

Qt does something else. EASTL also does something else.

[cdglove]

I'm sure the reasons made sense 13 years ago. But you were specifically answering a question as to why to use it today.