Comment by dkersten | Hacker News Reader

Comment by dkersten | Hacker News Reader

Parent Full thread

I'm curious as to why you wrote your own containers instead of using the C++ Standard Library, Boost, EASTL or any of the other existing container libraries. Care to elaborate? Eg, if performance or fine-grained control over memory is an issue, take a look at EASTL, which EA use in their games (and is designed to be suitable for both PC's and consoles). They are also extremely stable and well tested.

I've never tried to find C++ programmers on the market, but I do seem to come accross fewer and fewer C++ programmers now. I use a lot of C++ myself (amongst other languages, including Clojure, Java, Python and recently SML). I think having learnt it long before becoming a professional programmer may have given me a kind of attachment to it, but I actually enjoy using it (most of the time, I do often wish it did things differently or supported features I see in languages like ML or Lisp derivitives).

As for your interview question, the first seems almost trivial. The second, an intrusive stack, isn't very hard either [1]. I'm surprised that most applicants have trouble with them!

[1] Heres one I slapped together in ~5 minutes (no comments, only tested by running that code, etc etc): https://gist.github.com/827619

"I'm curious as to why you wrote your own containers instead of using the C++ Standard Library, Boost, EASTL or any of the other existing container libraries. Care to elaborate? "

A game developer disusses why he often writes his own data structures and steps out of STL and gives concrete examples at http://altdevblogaday.org/2011/02/15/data-structures-one-siz...

(fwiw I don't have a dog in this discussion. I don't use C++ and never will. The above is offered only because I had that page open in another tab when I read your question, and it seemed relevant)

Thanks for the link, very informative.

Personally, I will write my own data structures, containers or memory allocators when I have a task that doesn't fit nicely into existing libraries. There is nothing wrong with that. I am curious though when people only use their own. For example, I believe that when writing custom containers, providing STL compatible interfaces (perhaps alongside a non-compatible extension if needed) is a good idea because then you can use the STL when it makes sense, but your own when it doesn't (and pass data between them easily).

Having said that, I did not spend long looking at the code in question (nd in the sibling comment a good reason was presented for at least some of the custom containers), so perhaps it isn't realistic or reasonable to mix and match in this case. Still, I like to understand peoples reasoning because it helps me improve my own coding practices.

(Another author here)

The basic issue is that we didn't want to include external libraries, because it's a pain to debug, pain to build on multiple platforms and there are licensing issues.

Also we don't use so many datastructures, so we rolled our own and we are happy with them. For example we have an intrusive treemap, that has a function for returning the middle of a sorted key which is useful when you want to split a keyspace into two. Not sure if any of STL/Boost supports that.

Your solutions looks good, you are hired! ;) Seriously, we know that it is not that hard, but still the applicants have problems with it.

The C++ standard library shouldn't cause any problems on non-embedded platforms, including phones that support C++. Boost _may_ be a bit more tricky, though most of it is header-only, so it depends on the compiler more than the platforms (but if you use g++, there shouldn't be any issues). As for licensing, STL and Boost are both released under very unrestrictive licenses, similar to the C++ runtimes, so they won't cause you any licensing issues. Not too sure what license EASTL is released under. I know its an unrestricitve license, but don't know about the exact terms, so it may or may not be suitable.

Sure, obviously for niche tasks a general library may not perform as well as a container custom-made for the task at hand. That certainly is a legitimate reason to roll your own (though, if it were me, I would make my containers STL compatible, similarly to how Boost is STL compatible, that way you can mix and match between standard containers and custom ones and easily convert between them (eg, by using compatible iterators)).

Regarding applicants, I am just as surprised as you are. I guess I didn't notice how much C++ is diminishing in industry (outside of its niche areas, anyway).

PS: You're database does look interesting. May have to keep an eye on it.

Reply on news.ycombinator.com