I know in some areas (game industry, for example), STL is not recommended. So my question is: is it really a good practice not to use STL in some cases? If so, what's the biggest reasons of not using the modern C++'s STL?
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
I can think of only one valid reason and it's really rare: Hard real time. Many things in the standard library allocate memory internally and that is not deterministic enough for hard real-time applications, so they have to be avoided. These applications are usually quite simple, though they take disproportionate time to develop due to the very rigorous review and testing.
I can think of one invalid, but very common reason: Developers who don't understand computational complexity, misuse STL and then blame the library.
STL is usually faster at runtime than either C-style solutions with callback pointers or polymorphism-based solutions with virtual methods (see also this Bjarne Stroustrup's keynote). However when the developer does not understand the complexity specifications given and misuses the library by creating something like vector of vectors of some complex objects (in C++11 it's no longer a problem, though!), cause a performance problem and than defend themselves with "you see, the vectors are rather slow", it can cause a perception that standard library is slow. And once managers get such perception, it can live very long in the organization.
Obviously you can't use anything that the platform you are targeting does not support. However we are currently targeting four most common mobile platforms (Android, iOS, Bada and old WinCE) and use standard library and some parts of Boost on all of them.
Much of the standard library used to be unsupported by Microsoft early in WinCE (IIRC iostreams only came out with Visual Studio 2005), but it was possible to use STLport long before that instead. And you can usually get that to compile to anything. So I would call this reason invalid as well.
Besides, for quite long time it's not "STL", but ANSI C++ Standard Library. It's defined by the very same standard document that defines the language itself. Anything that does not support it does not really deserve to be called C++.
I'm using STL and boost for many years already. If I wanted to abandon it and use my custom tools, the motivation would be:
- Compile time reduction (75%). Just including iostreams can add 1 million lines of code to your module. Yes precompiled headers help a lot, but it still slows down the compilation a lot in big projects. In the long run, it wastes a lot of time of anyone working on it.
- Performance. (25%) STL is written to work generally, but you can optimise your structures to work exactly as you want. For example, you might have a data structures with millions of short strings. It might be much faster to use custom string class based on the principal of boost::small_vector (small static local vector of data, dynamic allocation only for larger strings), these kind of changes can make critical sections of code work many times faster.
There is one big valid reason not to use the C++ standard template library: One of your target platforms doesn't have a fully conforming implementation of it (or no implementation of it at all) and you know that it won't be getting one within the next years.
I do not know about complexity (efficiency of implementation) but I am using Qt containers and strings extensively instead of the std ones and they work fine. I also find the Qt implementation of sets and lists easier to use.
So, it can be practical to abandon the STL if you can use another library that fits your needs.
Patrick has mentioned the reason to not use the whole of the STL, namely that your platform(s) doesn't have one.
All in all I think the question is missing the point. It's mostly not an all or nothing decision, but one of pick and choose. You may well decide to go with the containers and algorithms, but decide to use something outside the Std Lib for strings and i/o.
It is not practical, unless there's a heavy reason to do so. Some of such reasons which I can think of include only partial or lacking implementation of STL(or any other part of the standard library) or a resource limitation(memory, CPU speed, storage, ...) which you have to get around by rolling your own tools which adhere to what you need to accomplish.
In game industry most(even smaller to some extent) studios have their internal libraries and implementations of many standard library parts which are highly tailored for the target platform and in some cases target engnie or even game itself. Simply put when developing a game for consoles the hardware is very limited by today's standards. There are thousands and thousands of lines of hand-crafted assembly for a reason. It's very important to minimize all kinds of resource footprints in your code so that the game runs faster which allows more content in the game world(or a bigger world for example) which hopefully results in a better product.
"Every succesful game starts by rolling out your own linked list implementation."