If you don’t know what you are doing, you shouldn’t blame the tools you are misusing; it makes as much sense as using nails because you don’t want to buy a screwdriver.

Moreover, what makes data structures and algorithms ‘wholly inappropriate for game development’ or ’suitable’? How can you tell before having an actual need? The STL provides some general purpose data structures, while this design attitude is likely to constrain you with overspecialized solutions.

I don’t believe any of the inconsistencies between platforms are really being resolved in the next release of the C++ standard – I just don’t think it’s at the top of anyones list nor would it be possible. Even if some of the points were revised to make the behaviour standard across all implementations, it still wouldn’t be perfect. There would always be areas of ‘interpretation’ and simple human error would introduce differences across vendor implementations.

The thing I would like to see is clarification, simplification and standardisation of allocator models in the STL.

The EASTL document is a fantastic read and I’d recommend anyone to read it, even if they were going with an implementation that was already out there.

I would generally agree with you. For personal projects, where code size and performance isn’t as important as at work, I would dip into Boost or a cross platform STL implementation without a doubt so I can skip to other areas I tend not to have the opportunity to concentrate on at work.reasons.

I would also guess that ‘Not Invented Here’ syndrome applies in many situations

Hi James, don’t worry about it not being about testing, any discussion is worth having no matter where it’s done

Unfortunately the question you ask is not an easy one. Ask 10 game developers and you’ll probably get 13 different answers so all I can do is give you my opinion and see where it fits with what you already know.

The idea of the STL is great for game development, especially in companies with shared code bases or technology. Having 4 projects being developed using 4 different types of list just isn’t sustainable, and I’ve always stressed that your version of a link list is understood by you and a couple of others but std::list is understood by thousands (or millions) of developers out there.

But you have a risk, especially in cross platform development, of using an external implementation. If you were to stick with the platform vendors version, you’re on a road to nowhere. In the linked article, it’s mentioned that in the VS implementation, clear() frees memory. That’s fine, we can deal with that, until you run on another platform which doesn’t free the memory. Such fundamental differences make it a nightmare to develop like this as you have to be aware of every platforms quirks when it really should be standard across them all.

Some companies I know have taken an implementation (STLPort for example) and made it their own, added it to their repositories and tweaked and developed it when needed. This avoids the cross-platform issues but it still comes with a lot of bloat. There are some fantastic containers in the STL, but sometimes it’s best to not use them for all the reasons mentioned, but when the opportunity is there, it’s easy to ‘just use it this once’. But this is certainly the fastest approach that avoids a lot of the problems you can have with external libraries.

Speed is often used as an excuse to not develop your own containers, and I would often agree – if you don’t have the time to fully optimise (or test) it will probably be slower (or broken) – but if you do, there is nothing stopping it being as fast or faster. We’ve benchmarked our internal STL implementation quite extensively, and it is slower in some cases but in the majority (and in areas we care about) it’s as fast or faster on all platforms, which is something we could specifically aim for.

If I was doing something on my own at home, or if I was at a smaller company without shared tech or code, I would be very tempted to use an external STL implementation (a cross platform one – not a vendor implemented one) as the overhead of a custom implementation either wouldn’t be worth it or would be too costly.

Like I said, this is all my own opinion, and (if Twitter is anything to go by) you’d get some very opposite comments on the topic, but it’s what fits your needs at the time.

I’ve written a couple of posts in the past related to our implementation based on the STL (which I hope to continue writing about soon) so that might give you a bit more information too.

You’re right in that RTTI is not enabled. We are generally used to living without RTTI in game development, especially in runtime code, so not having it enabled is the default setting. We could use it, in that we also usually don’t have exceptions enabled except in test code, but it’s something I’m simply used to not working with.

This is still test driven development, though it certainly isn’t pure TDD as you mention (I don’t write a failing test, make it work, write another one etc.). Implementation and testing are written at the same time for one of the objects, sometimes test first but usually a feature of the object and then the related tests which feedback into the implementation.

When another object is being developed tests can be introduced in the same manner, usually by removing them from a compiled out block of code, so the same process is followed, just with tests that happen to already be there.

It’s also interesting in that one of the benefits of TDD is that you refactoring towards a solid, usable interface, which when developing against a fixed standard like the STL, is already done for you. But every process needs to be flexible to the people using it.

Quite often the related classes (for example vector and fixed vector) are totally separate entities, with no shared based class (either functionally or as a pure interface). This is by design to avoid the overhead of inheritance and virtual functions so in this case the ability to extract common code is very limited, and even if it was, so much of the objects take into account how they are implemented that even simple functions like empty() and size() are unique to the type of object being developed.

As you mention, it is using the unit testing process to enforce a common interface and common behaviour and as a benefit places all the work and overhead of enforcing that into a project that is only used during development.

To me it sounds like it is not test driven code instead tests after the fact, but you do make the point of saying whilst under development.

“So for example, when developing a ring buffer style iterator, it was useful to know that the const and non-const versions produced the same results in a lot of different situations without having to have comparison tests or duplicating a large amount of test code.”

Unit testing is _normally_ an iterative process with one step (also a continuing one) being the refactoring of the test code, is what you are suggesting an early refactor or is this a result of the being templated code? I would propose that the duplicating code is what could be abstracted out, which in essence is what you are doing by using the defines and inline files, leaving simple unit test which call into this code.

As you mention that there is a upper bound which makes this implementation hard to read and I have a feeling that including the files in this manner may make the tests harder to read, yet obliviously you think this it is fine within reason.