Engineers often talk about premature optimization, but today I'm going to just talk briefly about the opposite, premature pessimization.
I currently work on a very large code base, it has been developed over four years from scratch. One of the first things performed were a series of investigations into "best performing" data structures, such as maps, lists and so forth.
Now of course one has to totally accept one can optimize any data structure that little bit more for a specific use case. One also accepts that when in C++ the standard library lends itself to being replaced bu defining standard operators, iterators and the algorithms going with all this use those standard exposed APIs, so you can implement your own.
I just want you to stop though and think... Do you want to?
Too early in a project and you can start to introduce bloat, either in terms of slight differences in the optimized cases, the code from whatever third party "best" you picked and even from your build chain, as you are bringing in dependencies on someone else.
The standard library doesn't do any of this, its dependencies are guaranteed by the ABI.
So why not just use standard map, or standard vector and standard string, or standard formatting?
Quite often I'm finding it is due to premature pessimization, that developers voice who cries out about some issue they had, either when some technology was new and emerging or late in an earlier project's life where they had to optimize for that specific case I mention, where the standard version did prove itself to be a detriment.
These engineers carry with them the experience, sometimes scars, from such exposure to edge cases and bugs they had to quash. Rightly and understandably they do not want to experience these self same issues again; their minds therefore are almost averted from just standing it up with the standard version. They immediately seek and even proactively nay-say the standard versions in favour of domain specific "best" versions.
This is in my opinion the very definition of premature pessimization, the standard library is wonderful, diverse and full of very well tested code and will have nearly zero overhead in adding and using to your project in C++.
I would therefore coach any developer with such mental anguish over just using the standard library to simply stand it up, just get across that line of things both building and running, then extend it to remain maintainable. And finally as you think you're getting close to stable, well then you can expend more time looking at, profiling, and understanding the edge cases.
