So I was looking through the Unreal 4 source and I see that they have everything as you would imagine, a whole string library pretty much the same as Boost. Now I guess they are so used to always writing their own as libraries as libs like boost haven't been around for long but I am guessing they could knock maybe up to a third of their code off from using libs like Boost, and various other highly optimised libs.

So what are your thoughts here, write your own or use third party?

It's going to depend.

For my own personal projects I tend to write my own because I enjoy learning new things by writing "from scratch" as it were. Though for things I've already written before and/or understand I'll use a library (i.e. C++ STL library) to save time. In these cases execution speed isn't a huge deal because I'm not writing huge AAA games with the latest tech at home.

Professionally it's also going to be a mix. You'll find a lot of companies using middleware like Havok or Unreal, texture loaders like DirectXTex, XML parsing libraries, etc. Not aware of many using boost - it tends to very quickly bloat compilation times and has the same problem STL has in that it's optimized for the general case.

There is, however, a bit of a stigma against the C++ STL library due to studios being burned by badly written implementations in the past - and in some cases, companies will write their own implementation of things like arrays or strings because they can actually write them faster or more memory efficient then the "standard" version for their particular use case.

A good example is the strings you brought up. A common thing to do is to write a string class that stores string data in a large table, and then if someone makes another string with the same data it points at the table instead of allocating more memory. Not only does this save on memory over the STL implementation (which has to allocate memory for every string copy), but you can get lightning-fast string comparisons because you only have to compare pointers and not whole strings. The downside is that these kinds of strings are immutable - but for a game, that is rarely a problem.

Edit: Most of the above should probably be prefixed with "In my experience" - though that may be assumed

a whole string library pretty much the same as Boost.

When it comes to the C++ standard library, and also tasks like string manipulation, there is a lot of subtlety involved beyond just the public-facing API.

Carefully read this report given to the C++ standards committee. You will probably find it enlightening, as it describes many of the tiny reasons the standard library doesn't precisely fit our industry's needs. Some of the reasons are common, even after 20 years there is no really good solution to the problem of allocators inside template collections as they relate to code boundaries. Others are less common, like the desire to bulk-destruct objects without calling their destructors.

The decision to use a third party library is never an easy one.

I personally don't believe in re-inventing the wheel, if someone has already done a really good job of doing something, why should I invest the time doing the same ?

However there are times when "the best out there" isn't good enough. Then you need to get involved and do some serious coding.

It's a cost versus advantage equation.

If using an external library saves you 3 man months of coding at the cost of 1ms per loop, it's probably an easy decision ... until you really need that millisecond

We use third party code, and pay a lot for the privilege. It's not always a good call. I've just saved 100's of milliseconds in a game because I noticed a problem in a third party library.

Now this library is very good, don't get me wrong, at times it's brilliant. However it was designed for a small number of animation tracks. We use thousands of animation tracks. Huge numbers of the damn things. So the code was doing something it wasn't designed to do, and hence it was slow.

I added three lines of code and increased the speed by several thousand percent. The code was simple, finding the problem was a bitch. I'm talking a 20 year old bitch with massive PMT.

Would we have had that problem if we wrote it ourselves? Hell no!

Would we get the game out on time if we had wrote it ourselves...... probably not.

The main issue with pre-existing libraries is that they rarely do exactly what you want, and it's frequently the case that said library needs a lot of wrapping before you can even use its unwieldly API. You end up doing things like writing C interface layers to poorly documented image processing libraries that think they're cute because they use longjmp.

That said, as terrible as most libraries tend to be, there tends to be at least one that's a very close fit to your requirements. The hard part is finding it, and the harder part is testing it, because those libraries aren't typically the massively battle-tested ones.

The other thing to consider as well as the very valid points mentioned above is that the Unreal 4 code base is based on code that has been around for a long time. Sure Epic may claim that it has been rewritten form scratch but I highly doubt that they wrote every single line. If they have a string or a collection library that they have been using and maintaining since they release Unreal in 1998 then I really doubt they are going to replace it.

but I also have MemCmpF which saves cycles by returning only true or false (as apposed to -1, 0, or 1, which requires a byte-per-byte scan once a discrepancy between the inputs is found).

You'd be at most saving one comparison actually. As soon as you find a byte that's different (not sure if it compares byte by byte or word by word or whatever, but the case is the same regardless of how it does it), you check if the byte is bigger and return based on that.

If you have four bytes 0x01 0x02 0x03 0x04 and compare them to 0x01 0x03 0x03 0x04, as soon as you check the second byte you know the second string is bigger, so you return 1. If the second string was 0x01 0x00 0x03 0x04 you'd return -1 after checking the second byte. The first byte that differs is the most significant byte that differs, so that's all you need.

As for the actual topic, there's always a desire to roll you own when you realize you need something. You always need to be aware of the 80/20 rule, though: 80% of the work will be done in 20% of the time. The last 20% will take 80% of the time. That is to say, you can get most of the way in a short time, which may make you think that you saved a lot of time, but actually taking care of all the edge cases, testing, debugging and the like that would get you all the functionality you need will take you the most time. Deciding whether to roll your own or use 3rd party libraries needs to be carefully considered, there's no simple answer.

The first thing you should do is understand what your requirements are, exactly. The better you can define your requirements, the easier it is to make a decision. Then look at the documentation for the library. Does it match your requirements? How much work would you need to do to get it all the way there? Look around, too, don't just settle for the first library you find. After this you should have a list of libraries that match your requirements. Compare those to determine which one is the best. Does it have an active community of users (good for getting help if you're stuck, and probably means it is in active development), does it have good documentation, does it have a bug tracker, are there any disqualifying bugs still around, is the interface reasonable and easy to use, is the build system simple, etc. Once you have the best of these, compare what it does to how much effort it would take you to match the parts that you actually need.

If you are convinced you can do it better in less time that it would take you to learn the interface, go for it. Otherwise, use the library.

Of course, writing libraries is great for learning too. If time isn't an issue (meaning, generally, a hobby project), do it yourself if you want to. What I generally do is write from scratch things that I think are interesting, and use libraries for things that are boring.