Years ago every C++ project worth its salt had at least one implementation of of strings, vectors and other basic things. I hoped we finally were past that.
Probably not as the way things are defined in the STL is often not in line with what C++ programmers want for their code base.
STL adheres to zero-cost-abstraction, which often puts safety in the backseat. Many programmers, myself included, prefer safety by default with an escape route, when its really needed.
Add to that things like exceptions, locale-dependent behavior, functions with a dozen overloads, an overly complex memory allocator interface (`std::vector` vs. `std::pmr::vector`), etc.
Personally, I'd prefer a common alternative to STL that focuses on these points. ETL [1] and abseil [2] come to mind, but it's not exactly what I envision.
1: https://github.com/ETLCPP/etl 2: https://github.com/abseil/abseil-cpp
There are people on the standard committee looking at safety, and some effort to see if more safety can/should be added to the standard library. Perfect safety is probably impossible, but there are several options being discussed. (operator[] is undefined if the value is out of range, but there is thought that perhaps checking range isn't that expensive and so we should throw an exception - it is possible that in many cases the compiler can prove the value is in range and thus the range check would be optimized out anyway). Safety profiles can also disable unsafe operations, and since they are opt-in (opt-out would be better but break too much existing C++) you choose when to pay the price. (if you have any other idea I'm interested)
And I've seen numerous explanations: someone wants more safety, someone wants less safety, someone wants locale-aware strings, someone wants ABI stability, and so on, it's an endless list. Few people are brave enough to admit that reinventing the wheel is just easier and more fun than solving problems people actually have and care about.
Well, I am in game development and all of the issues I listed above are actual problems that we encountered either in the past or still wrangle with today. Especially locale-dependent functions are a bitch on Windows.
Edit: one more thing I'd like add is that reinventing a wheel in C++ is quite horrible as it's such a complicated language.
We will never be past that is there are tradeoffs in implementing things. Safety was brought out in other comments, but there are others. In some cases a slower algorithm will be faster in the real world because it is more CPU cache friendly (depending of course on what N is, but often N is small enough). In some cases you can accept a less precise answer - thus making your algorithms faster.
For most of us, in most problem spaces, the above doesn't matter and so the standard library is good enough. There will always be those who correctly have a need that is strong enough to be worth building their own standard library though.
Whenever I've worked for a company that decided to re-implement all their own strings and containers, I'd always try to suss out whether they actually did it for one of those actual good reasons, or if they were just cargo culting someone long ago who once said "STL BAD IT'S SLOW" and that was all it took to convince them to write 20K lines of unmaintainable and unnecessary OurString OurVector, and OurList crap. So far, I've never found one place who knew why they reimplemented all that stuff. I do know one person who works in games whose company actually had a good reason to do their own containers, but these cases are rare.
Yes, since 1998, but apparently legacy code lives on.
At least in what concerns "strings, vectors and other basic things".
Now if you conside something like networking part of "basic things", then it is another matter.
Then again, vcpkg and conan exist now.