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?

  • related question Aug 16, 2012 at 6:59
  • some of my colleagues argue that, the iterator makes debugging harder, because sometimes it's not easy to step-in, and this also applied to the lambda. What's your response?
    – CaptainJH
    Aug 16, 2012 at 10:25
  • As for skipping stuff during debugging, see, for example: stackoverflow.com/questions/2062881/…
    – Martin Ba
    Aug 16, 2012 at 11:33
  • This seems like a good question. Maybe someone could add "Why would a project choose not to use the STL?" Mar 14, 2016 at 5:44

6 Answers 6

  • 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++.

  • 6
    The first argument (realtime) isn't specific to the STL parts of the Standard Library. sprintf often allocates memory too. On realtime platforms, the standard library functions also have deterministic limits. This makes realtime C++ implementations hard: you'd have to carefully develop a whole C++ standard library, which is more work than just the small C standard library.
    – MSalters
    Aug 16, 2012 at 9:02
  • @MSalters: Sure, many things can't be used under real-time requirements. Even some language features like exceptions can't. Still C++ is great language for these systems, because it can combine performance and precise control with strong safeguards (RAII is most important feature for that).
    – Jan Hudec
    Aug 17, 2012 at 8:29
  • @JanHudec: Indeed, that's why the STL parts are only required for "hosted" implementations of C++.
    – MSalters
    Aug 17, 2012 at 8:37
  • [problems involving] vector of vectors [...] (in C++11 it's no longer a problem, though!) Can you explain why this isn't an issue in c++11?
    – Elliott
    Sep 29, 2021 at 15:08
  • @Elliott, because from C++11 vector moves the members instead of copying them, so the member vectors don't get reallocated when the outer vector is resized.
    – Jan Hudec
    Sep 29, 2021 at 19:32

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:

  1. 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.
  2. 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.
  • 1
    SSO is already common. Oct 1, 2018 at 12:56
  • for the posterity: SSO --> small string optimization, i.e. most (all?) std::string implementations keep small strings on the stack and switch to the heap if need be
    – blue
    Jan 10, 2019 at 17:39
  • Compile times is a big one May 26, 2019 at 19:25

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.

  • 3
    Aka "don't use it when you don't have it", which makes sense, really. :)
    – Xeo
    Aug 16, 2012 at 7:18
  • 4
    Given that C++03 standard library is designed to be implemented in terms of ANSI C89 library only, is there any platform where you couldn't get at least STLPort?
    – Jan Hudec
    Aug 16, 2012 at 7:23
  • @JanHudec I believe there are platforms without STL because they don't have enough memory to handle the whole thing. Usually they are also missing some other C++ functionality (e.g. exceptions).
    – Sulthan
    Aug 16, 2012 at 8:02
  • 2
    @Sulthan: For microcontrollers I kind of understand, but those fall in the "hard realtime" category usually. For anything else, that's mostly preconceptions, because STL is usually just as efficient both memory and performance-wise as hand-crafted code. Lot of inlining may cause larger binary, but that could even be avoided by careful implementation at some performance cost (that a hand-crafted solution would have too). Missing exceptions are also either preconception, or laziness, because it takes effort to define and implement the exception ABI.
    – Jan Hudec
    Aug 16, 2012 at 8:18

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.

  • 2
    the Qt equivalents were created way back when there were no STL implementations that were either a) available, or b) any good. That's the only reason they are still used, nothing against the STL of today.
    – gbjbaanb
    Aug 16, 2012 at 17:42
  • 2
    I think Qt libraries and STL offer different interfaces and each developer should choose the ones he / she finds more comfortable to work with: there are still developers who prefer Qt to the STL, not only for historical reasons. In general I would advise to use the STL libraries if possible because they are standard. The question being asked is if it is possible to use other libraries and Qt is such an alternative.
    – Giorgio
    Aug 16, 2012 at 18:59
  • 1
    @Giorgio: the problem is in complex applications, where you're combining multiple libraries. The STL containers, being standard, form a lingua franca. More precisely, it's their conventions which do. The best-known example is Boost. It can work on STL containers. it can also work on Qt containers, but only because Qt has follows STL conventions - e.g. QList<T>::iterator
    – MSalters
    Aug 17, 2012 at 8:43
  • 3
    I didn't downvote it, but I see one reason: It's does not answer the question. You said there are things to use instead of STL, fine, but that's not a reason to avoid STL. Besides any reason to avoid STL probably applies to Qt, MFC and other such libraries as well or even more.
    – Jan Hudec
    Aug 17, 2012 at 9:15
  • 3
    @NoOne: We get that you are used to camelcase, not snakecase, but that doesn't make the latter any worse. And of the three function-names you criticize, the first is perfectly descriptive for anyone having anything to do with c-strings, and the other two are inherited from C, won't discuss those. Nov 2, 2015 at 14:51

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."

  • 2
    I would imagine every successful game starts by writing code using the standard library and then only optimising code once the game has been extensively profiled. Optimising before you have profiling data stating what needs optimising is pointless.
    – Cromulent
    Aug 16, 2012 at 12:42
  • 1
    True. The last phrase was just a play on the "ancient" way of writing games in early 90's or so, when C++ wasn't that widely deployed and assembly + C was the way to go. Perhaps I should've made it more clear. It applies well to the game industry in consoles though, most algorthms and data structures are hand-written by default because every byte and cycle counts(yes, even at the expense of maintainability/portability/whatever).
    – zxcdw
    Aug 16, 2012 at 14:25
  • 2
    It should be said, that it's more of an old experience living on. Modern optimizer will usually generate better assembly from simple maintainable code than the programmer will do by hand and the generic templates like in STL or Boost often inline to as efficient code as special-casing everything by hand. But there is a lot of code that started in times when that wasn't the case and lot of people who learned the trade those days and keep working that way even though it does not make sense anymore.
    – Jan Hudec
    Aug 17, 2012 at 9:13
  • 3
    @JanHudec The thing is that the implementations(and behaviors too, infact) need to be very tailored for the task. You simply just can't spare a few dozen bytes here and there(ruining locality of reference), drop in a few branches to validate input(branch mispredicts and instruction cache misses) and assume that the compiler knows how to vectorize your data-structures optimally to take advantage of SIMD(it won't, or at least you have to verify that what it attempts is correct). Of course writing real-time software on a PC isn't as strict, you can always throw in a faster CPU. Not in consoles.
    – zxcdw
    Aug 17, 2012 at 13:13

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.