Original Post
I, like many others, had previously set out to write my own custom version of std::vector. I was initially happy with the result; it was a container that routinely exceeded the performance of std::vector by sacrificing contiguity for speed. For a while, I continued to use this class in my code with an air of blissful ignorance. Then came the time where I needed to fix some things that I had previously forgotten to implement. Things like copy constructors, comparison operators, assignment, and the like. "OK", I said, "That's not too hard". I implemented them and continued on with the rest of my program, fixing bugs as they popped up. Later, as I began to use std algorithms more, I found that I hadn't implemented iterators for my container, so it wasn't STL compatible at all. After attempting to implement custom iterators (and failing miserably), I discovered that my code wasn't exception safe, either. I found a lot of potentials for memory leaks and lost data if an exception occurred. I then realised that whatever tiny performance benefit this class could give me was being heavily outweighed by all its problems. I found myself constantly looking through the std::vector code in an attempt to understand (and copy) it, which I realised was quite a silly endeavour. I've switched it all over to std::vector, now, and everything's working wonderfully. I've learnt my lesson now, and I'm not going to attempt to reinvent the wheel "just because I can". For anyone else that is thinking of implementing their own version of an existing STL container/algorithm/function or reinventing the wheel, then I can only warn you to stop and consider the costs and benefits. The STL is well designed, guaranteed to work, and still relatively fast. From my experience here, it's not worth the work, effort and time to implement your own version of the STL unless you have a really, really good reason for it.
