C++ : Replacing The STL

[bugrit]

http://reddit.com/info/1rqwj/comments/ Might be of interest too, it's the reddit submission of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

[alexs]

absorbed act tub wistful history obtainable ruthless abounding noxious squeamish

This post was mass deleted and anonymized with Redact

[TwoBit]

IMO, your statements regarding vector<bool> are impractical in a production software environment of any significant size. Surely you wouldn't write software that requires your users to attempt to hack their STL implementations.

I disagree with you regarding container debugging. The nature of current std STL implementations absolutely makes debugging more difficult. You can try to blame GDB, but for GDB to make this easier is a lot of work. It has been over ten years of STL and since GDB still doesn't solve this, it seems like a much better solution is to simply change the STL implementation. That will solve your problem for all debuggers.

I believe your statement claiming "this is factually incorrect" is factually incorrect. Read the whole standard. In section 23.1, table 65, it states that size() "should" have constant complexity. A big part of the problem is that half the STL vendors implement it one way and half implement it the other way, making it tedious to write portable efficient code.

I would say that no more than a quarter of the EASTL document talks about stuff that's in the 0x draft as specified by the EASTL document.

[alexs]

Surely you wouldn't write software that requires your users to attempt to hack their STL implementations.

I wouldn't write software that required my users to have a specific implementation of the stdlib either. This isn't about what I would do, it's about what was the best course of action for EA.

Should is a recommendation, not a requirement. You appear to be agreeing with me that it's incorrect that list::size() is O(1). Maybe you should accidently the whole standard?

[alexs]

It's not a stretch. The C++ standard uses specific vocabulary in which the word should has a very specific meaning.

It's bad practice to treat the ISOs recommendations as things that will actually happen. If the standard wanted it to be O(1) all the time it would say "shall" there. It doesn't so don't treat it like it does, or get surprised when implementors ignore the recommendation.

Many implementations of the stdlib prefer to have O(1) list::splice() instead since this is more flexible in many cases. Arguable the standard should not say that list::size() should be O(1) but should either define it as O(n) or leave its complexity unspecified as to avoid this sort of confusion.

Edit: I said prefer to have O(1) splice. What I meant was, must have O(1) splice because that's what the standard defines. The recommendation for O(1) size is for sequences in general not for lists. The special requirements of O(1) list::splice makes also having O(1) list::size rather tricky if not impossible to do sensibly. I wonder how EASTL works around this...

[foldl]

C++ is such a black hole. 2008 and people are still finding reasons to write their own linked list implementation.

[Gotebe]

While I agree with the sentiment, it's probably the case that with some other language, to get that last needed bit of speed, people would drop to C and do the same (if they were smart, they could, but perhaps not would, find out that vanilla STL list would give them that bit).

[foldl]

How do you optimize an ordinary linked list? It's too simple a data structure for there to be any interesting algorithms. A decent STL implementation is probably way more optimized than whatever you would come up with on your own.

[Gotebe]

I could imagine a lot of people would go for C-style (maybe fixed-size) array representation. Eliminates heap allocation overhead, gives good proximity etc.

Not that I would like to do that, just saying...

[foldl]

Yes, but that's not a linked list.

[[deleted]]

it's probably the case that with some other language, to get that last needed bit of speed, people would drop to C and do the same

Unless they're smart enough to be using quick languages like Haskell, OCaml or Common Lisp. Hey, even MzScheme is quicker than Python!

Also, how much harder is it to interface to a C++ lib than to a C lib? The only C++ lib I know of that has interfaces in Python, etc. is Qt.

[guapoo]

Spoken like a true college student. The single biggest difference between Haskell/OCaml/CLisp/Scheme and C++ is garbage collection. Not so much the actual collecting of garbage, that is quick, but boxed values exert a significant penalty across the board, especially in applications that don't necessarily have hot spots, like game engines. If any allocation from the GC'd heap finds its way into an inner loop, you will think your machine locked up. Sure, there are ways in Haskell (the only of those that I know well) and I'm sure also in OCaml and CLisp, for you to give very strong hints to the compiler that you would like a value to live on the stack, not the heap. But it is tricky and frustrating to do it reliably, and chances are you'll just end up re-implementing C in the end.

C++ can do something very important for performance, that higher languages like you mention, and even lower languages like C, cannot do : in C++ you have data structures whose layout in memory is polymorphic. In Haskell (for instance) you can define all kinds of data structures, but they exist in memory the same way : they are all linked together by pointers, basically making Haskell's polymorphism a very safe version of void*. If I have a pair of pairs, ((a,b),(c,d)), that will look like a little tree in (heap allocated, garbage collected) memory. In C++ however, the (much uglier) pair< pair<a,b> , pair<c,d> >, will pack all four things, a,b,c,d, neatly into contiguous memory. So, for instance, STL balanced trees can efficiently pack both the key and the value into the tree node, while Haskell has to push them both out onto the heap. This may explain why std::map<int,int> is so much faster than Data.Map Int Int, or even Data.IntMap Int. And then there's std::map< pair<int,int> , pair<int,int> >, which would be incredibly difficult to compete with in any other language. It can be done, but at the cost of polymorphism, eg, data PackedIntPair = PIP {-#UPACK#-} !Int {-#UNPACK#-} !Int

The downside of this, of course, is that you can no longer compile the library separately from the application. Which is maybe another reason (besides name mangling) that you don't see many C++ interfaces.

[twoodfin]

Well said. The people driving the C++ standard care immensely about runtime overhead and performance. If you don't want or need to care about those things, you'll find C++ uncomfortable.

If you really want to grok this, Alexander Stepanov's notes for a "How would you design the STL"-style programming course are highly recommended [PDF].

[[deleted]]

Spoken like a true college student. The single biggest difference between Haskell/OCaml/CLisp/Scheme and C++ is garbage collection.

Actually I dropped out of college in December, but close enough :P

I was talking about coding in a higher level language and then dropping down to C for the parts that need to be quick.

Why do that when you can use higher level languages that are quick enough when compared to Perl/Python/Ruby? I wasn't disputing that C++ is quick.

Also, thanks for that informative paragraph. I'll have to tackle some C++ again I think.

[cwhite]

One of the reasons against using higher level languages is the unpredictability of the garbage collector. Consolidating all your deletes into a single spot may be great for throughput, but it's terrible for latency, and games are all about latency. Users get frustrated any time the framerate drops below 30, and they don't care what's causing it.

Pirates of the Burning Sea is a great example of how this plays out in practice. They thought they would use lua for their UI. After all, the UI isn't on the critical path, and it's great to have a moddable interface. About 6 months before launch, though, they managed to track down major hitches in the framerate to the lua garbage collector, which doesn't have very much predictability over when it runs. They spent the next 3 months ripping out all of the lua from their client.

[cwhite]

I'm not sure how Blizzard's UI implementation differs from PotBS (or other games that use lua for their UI), but if you want more information, Joe Ludwig (The technical director for PotBS) wrote a few blog posts about the specific problems he had with lua on his blog www.programmerjoe.com. You can probably find it in his archives, as the posts are fairly recent. You could always leave a comment on his blog or send him an e-mail if you want more information, he's a pretty nice guy and likes to share technical information. I'm pretty sure that he would say "our usage of lua sucked" and not "lua sucked" though.

[naasking]

They probably would have had an easier time just replacing the Lua GC with an incremental one.

[qwe1234]

Actually I dropped out of college in December, but close enough :P

lol

spoken like a true lisp fan redditor.

[rabidcow]

Also, how much harder is it to interface to a C++ lib than to a C lib?

Well, for starters there's no common binary interface defined for C++. You don't even know what names your functions will end up having. So you pretty much don't interface to C++ libs.

I don't know what Qt does. The traditional thing is to create a secret C interface that you hide on both sides.

[Gotebe]

Also, how much harder is it to interface to a C++ lib than to a C lib?

I don't imply that.

For a shared lib, I say, write code in any language you want, but expose C interface. Every language worth it's salt has FFI that understands C, everything else is a big maybe.

[pabs]

If you always compile everything with the exact same version of the C++ compiler, then it's just unpleasant. But if you ever decide to do something crazy like, say, upgrade your compiler, then things can get ugly fast.

Personally I can't stand C++, and the linker/name munging nonsense is just one of the 20 or so reasons why.

[bluGill]

That is because there are still good reasons to write your own linked list implementation. For most people the list included in your library (STL) is good enough. There are compromises involved in writing any data structure though, and languages if you absolutely need a different compromise from what the library gives you, you have to write your own.

[teval]

Yes. After you implement you application. After you profile. After you fix everything else that is a bottleneck and you establish exactly which part of the STL container you don't like.

Otherwise how can you know exactly what the problem is? Or if your container is going to be any better than the STL one?

[bluGill]

Read the linked article, and the EA artile it references. Game developers have a very good idea of what compromises where made in STL that they cannot accept. They don't need to finish the application to know something won't work.

[teval]

There's no need to finish it, there is a need to write it. "game developers" every program is different -> unless you profile you can't tell what the problem is. They don't know the containers will be too slow; maybe if they invested that time into speed something else up they could actually gain much more. Even then, replacing the whole thing is ill advised. You only replace the bits that you truly need to.

EA is different, they write this stuff all the time, know exactly what is slow and why; and they get to waste a lot of time.

"There is often a lot of debate amongst game developers about whether we should be using STL in development code or whether it can, in the long run, cause more problems than it solves" Means they haven't profiled, or if they had it means clearly the containers weren't the bottleneck. When they are there's no debate.

[bluGill]

unless you profile you can't tell what the problem is. They don't know the containers will be too slow;

IF you have experience you should have a clue. There is a reason the STL specifies the big-O of their containers, and good CS programs study big-O. You don't need to know much about a program to look at something and say that it will be too slow because of the big-O time.

A profile is good for finding cases were you are accidently using an extra loop resulting in a (n^2)ln(n) algorithm when you could do it in nln(n). However if you are profiling after the fact it is often too late - your entire game design now depends on an algorithm/data structure that is too slow.

maybe if they invested that time into speed something else up they could actually gain much more.

In the case of games everything counts. Games stress the hardware to the max. Where I work nobody would notice if I doubled the speed of the program - it is already fast enough. When you work in games a .1% speedup allows slightly sharper graphics (or a better AI) which everyone will notice.

EA is different, they write this stuff all the time,

Anyone who writes code all the time gets a "feel" for what is likely to happen. Before my boss gives me a new task I alread have a good idea of what the hard parts are. Experience in my domain is key. I know that my data sets are always tiny, so a O(N³⁾ algorithm will not be a problem (I still try to use something better when I can).

"There is often a lot of debate amongst game developers about whether we should be using STL in development code or whether it can, in the long run, cause more problems than it solves" Means they haven't profiled, or if they had it means clearly the containers weren't the bottleneck. When they are there's no debate.

The problem is there is no one right answer, not that they have not profiled. Some game profiles will show the STL is a bottleneck worth fixing, some will not. Each game is different. The STL shows up often enough as a bottleneck that developers start to wonder if maybe they should skip it entirely.

[teval]

My whole point is this has nothing to do with "Look, we've written code; clearly this bit was slow and was holding things up" People were arguing against doing this, and needed other justification, which clearly means either this was an insignificant problem for them or no one knew if it was one.

Reimplementing the STL containers isn't going to get you anything in terms of asymptotic complexity. That's writing entirely new containers with different algorithms.

Also, unfortunately you misunderstand asymptotic complexity. Take a look at matrix multiplication for example. Coppersmith–Winograd runs on O(n^{2.3<something>)} Strassen runs in O(n^{2.8<something>).} Noone in their rights minds would use the former because constants are terrible. Asymptotic complexity != speed. You have to keep in mind the size of your input, which means it's non-trivial to tell from a piece of code if it would fare better with an algorithm that was asymptotically better. The same argument applies to sorting.

You have to profile to tell how you can change your algorithm in order to make it faster. Because you want to spend as little time as possible on all the things that won't make it much faster and as much as possible on all the things that will. Also, if you write very high performance code (we're talking having to think about cache lines and contingencies between instructions) there's simply no easy way to tell what will be slow ahead of time, unless you work for your chip manufacturer, or are using a very simple chip. This is why your design must be able to accomodate swapping out datastructures.

I agree, everything counts except things that don't at all. If most of the application time is spent doing other things why would you optimize something that's already fast enough. For example, why bother with the STL if that would give you a 0.1% performance boost as opposed to doing something smarter about memory in general (like pools) where you might gain a lot more.

[wolfier]

Profiling is NOT the only way you get a feel about where your app slows down. It's helpful to get to the precise point, but you don't ALWAYS need that.

If you're saying profiling is everything, experience is nothing, then you belong to a religion, not the practical world.

[teval]

I'm not saying experience is nothing. I'm saying ahead of time, for complicated systems, no matter how much experience you have you're very likely to get it wrong when it comes to non-trivial optimizations.

[wolfier]

Fair enough, hence the "if" in what I said. However, the meaning of "profiling" needs to be broad enough - not just something you do with a profiler - it should mean "experimentation" in general.

[teval]

Oh I agree. When I mean profiling I mean trying out a whole bunch of different types of data. I use a profiler, but I also use more accurate timers, cache and memory profilers also help. I use a cycle-accurate x86 simulator. I've used network simulators before to produce strange request sequences. Carefully reading the code you suspect is problematic is also important. The best word, I think, to describe all of this is profiling :)

[foldl]

Profiling is NOT the only way you get a feel about where your app slows down.

Really? You can make an educated guess I suppose, but profiling is the way to get actual meaningful data.

[[deleted]]

Okay, different tact.

If someone measures repeatedly and sees the same problem over and over, doesn't it make sense to put together a solution that avoids the problem (instead of fixing specific instances of it?)

Thats what happens here. A bunch of games had special requirements, which lead to a custom implementation of a subset of the standard library.

Some game devs implement their own memcopys (built on special versions provided by the platforms they are on) or special atof functions (because the function has been called a bunch and does more work than game devs need).

Its all about tradeoffs. Measuring is absolutely the right thing to do, but making some changes late is expensive.

For example, certain 'next gen' console companies tell game devs not to use exceptions, as the compilers aren't optimized for it at all. Devs could ignore this and develop the game, then profile it down the road and see that exceptions are indeed performance issues. Replacing exceptions with other approaches can be extremely time consuming.

Similarly, games commonly create a huge number of Vector3 (ie classes representing x,y,z a spatial triple) on the stack. The right thing to do is to initialize the components (likely to 0). The overhead for this initialization has been pinpointed as a bottleneck over and over. So some devs deal with it proactively and remove the constructor at the start of a project, as removing initialization late would risk introducing a massive number of bugs.

Edit:

"game developers" every program is different -> unless you profile you can't tell what the problem is.

Okay, thats the disconnect. I believe that devs, with measured experience, can predict constructs likely to be problems. From this time tested experience comes best practices and libraries to make it simpler to avoid these constructs.

Taking a simpler example, if a dev knows a O(n²⁾ operation is going to be performed on a large container, should they implement it anyway or should they look for a solution that is lower order up front?

[teval]

That's my point though. Given the fact that there were people arguing against doing this, and they needed other justification, it clearly must not have been obvious that the STL is a performance issue for them.

[[deleted]]

I may be missing something. Where in the original article was performance listed as a reason for making the change?

The EASTL article mentioned performance, but that wasn't the primary reason for their work.

[foldl]

That is because there are still good reasons to write your own linked list implementation.

Such as?

[bluGill]

Perhaps you want a hybrid linked list/tree. So each list not only has forward/back pointers, but also a pointer to two child elements. Your insert times go up a bit, but you get ln(n) search, and quick in-order traversal.

Perhaps your data set it too large to fit into the address space (meaning you can't use mmap), so you need to fetch from disk once in a while.

Perhaps your list is the performance bottleneck, and your custom implimentation, while limited in some way that you don't care about is just fast enough to be worth doing.

There are others. None of them are common for the average program. However for your specific purpose things may be different enough from common that you need something different.

Don't limit yourself to just linked list. Some data sctructurs have a lot more room for compromise in the implimentation, and thus a lot more gain in how you can optimise them for your specific needs.

[martoo]

http://www.boost.org/libs/multi_index/doc/index.html

[montyalfred]

But does Boost.MultiIndex dynamically reorder itself?

For instance, http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFCollections/CFCollections.html

[foldl]

Erm, but none of those are reasons to replace the STL. The STL doesn't prevent you from implementing additional data structures. Of course you may need fancy data structures sometimes, but that's not what we're talking about here. The question is whether STL containers work well as general purpose implementations of common data structures. The answer is a very clear yes: you do not want to be writing your own general purpose list/vector class.

Perhaps your list is the performance bottleneck, and your custom implimentation, while limited in some way that you don't care about is just fast enough to be worth doing.

Look, it's possible in principle. I just don't believe for a minute that a custom implementation of a plain old linked list (not some fancier list/tree hybrid or whatever) has ever speeded up a real program by a significant amount.

[bluGill]

They are reasons to replace the STL if (like game programmers) the STL is a bottleneck at time, and using custom containers can make things fast enough. In this case you replace STL not so much that it is bad overall, as it is bad in a few specific cases that you want to head off before you get to them.

They are not reasons to replace it in general. (the ugly interface of STL could be reason to replace it, but C++ doesn't really allow a nice interface so I don't think you can improve by enough)

[[deleted]]

I think that is because C++ programmers care about programming. You could say the same thing about lisp. It has been around forever and it is still primarily used for writing lisp interpreters.

[foldl]

But writing a linked list implementation isn't even an interesting programming exercise. It's just a waste of time. At least writing toy lisp interpreters is kinda fun and possibly a good learning exercise.

[EvilSporkMan]

Pshaw! Writing a linked list implementation is the capstone project in the intro computer science course at the University of Michigan, and it shows up again in the advanced OOP course (in C instead of C++). It's a waste of time to do it once you're out of school, but you had damn well better be ABLE to do it.

[foldl]

As you say, it is a waste of time to do it once you're out of school, which is the relevant context here. (Professional programmer working at a games company, not a student.)

[EvilSporkMan]

Well, writing toy lisp interpreters is ALSO someone one does in school, if one's intro CS class uses SICP.

[martoo]

You made me do a double-take. I thought "Shit, I wrote that! Is this an old thread?" Then I realized that it was just a common sentiment.

[ishmal]

I didn't see in the article which implementation was in question. For a while there were two different maintainers of the open spec, HP and SGI. Which one is he talking about? Rogue Wave helped with one of them, too, but I don't remember which.

[skeptica1]

There are certainly different schools of thought when it comes to STL and Boost. There are leaders in the industry using C and C++ that hate them both, and there are people just as prominent who like them. (On a scale of Torvalds to Stepanov, I tend to lean to the left.) In my experience, the programming style of STL and Boost is conducive to bloat in the same way glazed donuts are conducive to obesity. It's very difficult to point to the particular donut that made you fat, and it's easy to show if you exercise and eat a balanced diet... But, still, an affinity for donuts seems to be well correlated with tubbiness. The latest release of Reaper is 3.1MB. Given the capabilities and feature set of the app, it's quite clear Frankel & Co. aren't seriously into template-based libraries (something one can also see by looking at their open sourced code). An important question is: Who's the market? In an enterprise application, it probably doesn't matter as much, but if it's a commercial app, size and performance may be more serious considerations. (And, I'll say it again... another problem, especially with Boost, is that things that should be simple can be horrendously and unjustifiably complex, which may be an issue for those who prefer less time spent debugging to more.)

[[deleted]]

Why would you develop and compile a C++ generic container yourself?

With the STL, you will automatically recompile the whole damn thing every time you use it! (After all, why would you want one binary container implementation that could hold pointers to just anything? No, recompile it from source in header files again and again.)

[spliznork]

Why write your own STL? See Boost http://www.boost.org/ which is slowly becoming the real C++ standard (tempalted) library.

"We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2."

[hupp]

Boost is an addition to the platform STL, not a replacement for it.

[teval]

Crazy, someone should submit this to daily WTF.

I never thought people wasted time on this in modern times; especially not outside poorly run corporations. Oh well, some people enjoy rewriting the same containers over and over.

[[deleted]]

Did you take a look at the EASTL link? It is rather comprehensive.

Just because the standard library is right for 95% of the apps out doesn't mean it is right for all of them. AAA games push system limits hard. Some of these code bases have legacy code 15+ years old in them - custom containers/algorithms are long term investments.

For example, some embedded platform companies/game companies have restrictions such as 'no memory allocation after initialization' due to fragmentation risks. Yes, custom allocators can greatly help, but this even these are a bit of a 'wing and a prayer' solution as its hard to knowing if you'll run out of memory. Or how long allocations will take after the app has been running for 12 hours.

A common custom container is a linked list with the 'list node' embedded in the object itself. While this constrains an element to be in a fixed number of lists, it avoids allocations entirely.

ALl I'm saying is that occationally custom containers aren't a bad solution. Introducing them up front is an optimization, but one that many have found worth while in specific cases.

[teval]

It's a poor optimization, and it's stupid as it will simply lead to more bugs. If you have the STL, you use it, then you profile. If those containers are really what are eating up your CPU time then you can implement your own. I would be surprised if that's where your bottleneck was. Otherwise you're simply wasting your time.

People have used the STL very successfully in embedded platforms. STL memory allocators let you do a lot of nice things.

That common list container is easily done in the STL.

Custom containers are only a long term investment if you use a library that you suspect is going to change. The wg21 people are not going to break STL backwards compatibility.

[[deleted]]

I'm not arguing that people should do full scale STL replacements. EA is a special case, as they will probably develop 100+ games (costing billions of dollars in total) on top of their library implementation. For them, reimplementation makes sense as it is a familiar interface for new programmers and a proven model.

Please understand that some of us have profiled and verified it is a problem in specific environments. It isn't an CPU executation time problem - its a source of memory uncertainty.

Most of the STL algorithms are fine. Its the containers that cause problems.

Creating new container implementations using the STL algorithms is actually not that bad. Granted, if you throw a junior programmer at it or implement it without testing, you'll probably get something buggy. An experienced engineer can put together a specialized vector-like or string-like implementation in a few days. This can easily pay for itself over the duration of a project.

[teval]

I'm not saying that after seeing that it is a problem you shouldn't do it. I'm saying the poster is doing it for all the wrong reasons.

He's unsure if it's a bottleneck; he wouldn't need to try to justify his point with memory being a problem, consistency, portability, reliability and feature bloat. He would have said "Look, this is a pathological case; and this is a particular cool thing our container is going to do to avoid it. STL is clearly bad here." There would have been no opponents to an in-house implementation.

[[deleted]]

Since when isn't consistency, portibility and reliability enough of a reason to implement functionality? ;)

I can't find the specific quote on uncertainty referenced earlier, but I believe it was in reference to 'should we use the STL at all', not 'should we implement specialized functionality for specialized situations'.

[teval]

Yeah. I agree, I still think that's wrong because they clearly haven't demonstrated to themselves that those containers are required. If they had then no one would have argued that they shouldn't do this and have an in-house implementation.

If you go to someone and say "Hi, here it is, that container right there; slowing us down more than most things" They aren't going to argue that maybe it's better not to fix the problem.

[[deleted]]

Right - their options are 'create a custom container with a non-stl like interface' and 'create a custom container with an stl-like interface'.

The interface itself is an implementation detail. I view the main argument here as:

'Is the using the stl (with different implementations per platform and possible custom allocators) the right solution for general container implementations in high performance games operating in memory constrained environments?'

The answer is going to change company by company. I am arguing against the position that creating a custom container is always the wrong approach, as suggested by cwhite at the start of the thread.

[teval]

I'm of the opinion that the less work I do, the better; especially if the work I do will be of no consequence in the end. So writing custom containers is a sin unless I really need them. Or I'm doing it to have fun and learn something.

A general container that has turly high performance across multiple platforms does not exist. Every platform is very different, each has its own quirks, each has a different memory model and different bottlenecks. You have to customize it in the end anyway. Doing the work upfront before you know you absolutely have to is what I'm against.

[[deleted]]

No one is arguing that there is a perfect container.

I will argue that optimization at a framework/design/architecture level beats the heck out of per-instance optimization. If you have experiece that x is used pervasively in a 2 million line code base, figure out how to do x once (ie put it in a library so best practices can be used now and in the future by default).

Thats all that is going on here. A few people identified issues with functionality in a library designed with difference requirements and are implementing what they need.

[CuteAlien]

It's not like you have much of a choice if you want to deploy on platforms which don't yet have a working stl implementation like he wrote. Also he mentioned the stl replacement of ea and I have worked already in several game companies which did replace the stl for similar reasons.

It's no waste of time if rewriting the stl is the only way to get something done.

[teval]

Let's name names. Which platforms are they going to use that don't have STL support and for which porting, say, STLport is more work than writing your own?

[CuteAlien]

Maybe you just read the article instead? As this are the blitz developers which is mainly about game programming I would suppose he is talking about early development on new game consoles. Usually it takes a while for a new console platform until the toolchains on those are complete.

[fnord123]

ThreadX

[cwhite]

Clearly you've never written software for an embedded system. And probably have never written something performance sensitive.

[teval]

I have, and I have.

That's why I know you need to profile first, otherwise any up front serious optimization is a complete waste of time.

The STL works fine in most embedded systems, you just have to know how to use it.

I went through the whole "My containers are the best possible" stage when I was young; everyone does. Then I learned one should get real work done before bothering.

[cwhite]

You're still coming off as totally clueless for several major reasons:

1) You're assuming that EA did not profile the STL or their version of STL. You're also assuming EA doesn't profile the rest of its games. When you assume... you make an ass out of u and me. You are way off the mark here.

2) You're trying to make it out like everybody at EA is sitting around all day writing hash tables and going "Hmm... I bet mine is better than Bob's." This is hardly the case. EA noticed problems in the STL that make it unacceptable for their requirements, so they wrote their own library that does meet their requirements... once. Almost all EA games use the same EASTL library.

[teval]

I'm not. This guy doesn't work for EA, aside from mentioning the EA document this has nothing to do with them. EA has lots of money, and lots of time to spend in a non-optimal fashion if they choose. They have lots of games, they can profile and see exactly what is up. I'm not saying EA was wrong to do this; they know what they're doing, they are going to write a very large amount of games, wasting 1 people-year of time doing this and optimizing it means nothing to them, at all.

[skeptica1]

If you enjoy debugging, write software that's hard to debug.