21

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?

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
CaptainJH
  • 409
  • 1
  • 3
  • 5
  • [related question](http://stackoverflow.com/questions/174449/) – fredoverflow Aug 16 '12 at 06: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 '12 at 10:25
  • As for skipping stuff during debugging, see, for example: http://stackoverflow.com/questions/2062881/how-to-skip-common-classes-in-vs-2008-when-stepping-in – Martin Ba Aug 16 '12 at 11:33
  • This seems like a good question. Maybe someone could add "Why would a project choose not to use the STL?" – Matthew James Briggs Mar 14 '16 at 05:44

6 Answers6

26

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

StanOverflow
  • 103
  • 3
Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
  • 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 '12 at 09: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 '12 at 08:29
  • @JanHudec: Indeed, that's why the STL parts are only required for "hosted" implementations of C++. – MSalters Aug 17 '12 at 08: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 '21 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 '21 at 19:32
  • `vector` uses bits, rounded up to nearest byte); also an access to a single element incurs 3 cache misses. Compare this with `vector` of size 120,000, which uses 15,024 bytes in total, and a single access will incur only a single cache miss. – Elliott Sep 30 '21 at 02:13
  • @Elliott That applies to any use of array-of-arrays-of-arrays instead of multi-dimensional array. But as long as you want array-of-arrays (e.g. because it is a jagged array), `vector` does not create any significant pessimizations now, which it used to with re-allocations. – Jan Hudec Oct 01 '21 at 18:40
  • Well I thought that post was about how people can unknowingly misuse the library? I see `vector` of `vector` used when people *don't* want a jagged array and should instead use `boost::multi_array` (it's crazy that it's not in the the STL, tbh). – Elliott Oct 02 '21 at 01:40
  • @Elliott, the post was about how people can unknowingly run into C++ quirks. It is 9 years old, and back then C++11 with move semantics was still brand new and not supported on many platforms yet. Move semantics fixed a lot of those quirks. – Jan Hudec Oct 02 '21 at 14:42
9

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.
Marwin
  • 191
  • 1
  • 2
6

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.

Patrick
  • 1,873
  • 11
  • 14
  • 3
    Aka "don't use it when you don't have it", which makes sense, really. :) – Xeo Aug 16 '12 at 07: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](http://www.stlport.org/)? – Jan Hudec Aug 16 '12 at 07: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 '12 at 08: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 '12 at 08:18
4

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.

Giorgio
  • 19,486
  • 16
  • 84
  • 135
  • 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 '12 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 '12 at 18:59
  • Another down-vote. I guess on this site it is not possible to express any opinion regarding the C++ STL other than: "The STL is the only true C++ library". I explicitly wrote that (1) I do not have information about the efficiency of the implementation (the STL is probably faster than Qt) and (2) that using a standard library is a better practice than using a non-standard one. Then I honestly reported my experience (and that of many colleagues of mine): you can write great software with Qt and certain classes have an interface that some (not all) find more intuitive to use. – Giorgio Aug 17 '12 at 08:03
  • 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::iterator` – MSalters Aug 17 '12 at 08:43
  • @MSalter: Actually, in the company I work for we have several extremely complex products (Qt, STL, boost, and tons of other libraries, both external and developed in house) that use Qt heavily (both for the GUI and for general-purpose stuff like containers, sorting, strings, etc). Maybe, as you say, this can work because Qt follows STL conventions, but then, where is the problem? – Giorgio Aug 17 '12 at 09:06
  • 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 '12 at 09:15
  • Besides saying that there are other libraries, I said that one might find these other libraries (Qt, MFC, ...) more intuitive (which is, of course, subjective). In this case, using another library is both possible (practical) and motivated (easier to use). – Giorgio Aug 17 '12 at 09:31
  • I agree. STL (or whatever its name is nowadays...) was designed in an era when there were no IDEs, no Intelisense, not anything. So they've tried to make every method short and cryptic. This creates names that mean nothing to a modern programmer (e.g. `c_str`, `strcoll`, `strxfrm`), the function names do not reveal exactly what each method does (e.g. the Get*/Set* convention is totally lacking) and the casing of methods is also terrible (e.g. `pop_back()` instead of `PopBack()`). And people start copying those patterns! C++ is a good language, but these standards give it a bad name. Qt or MFC. – NoOne Dec 16 '14 at 19:14
  • 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. – Deduplicator Nov 02 '15 at 14:51
  • @Deduplicator In my opinion camelcase helps identify methods much easier than other casings. I think snakecasing is counter-productive for reading the code. C++ had a lot of weird characters in use already. It didn't need the underscores (that resemble much with spaces or minus symbols at first look) in its standard libraries. Anyway, the Get/Set convention is missing and using characters like underscore makes coding a bad experience. – NoOne Nov 05 '15 at 18:00
  • @Deduplicator You might think these are small things, but remember how obsessed people are with using C++'s `{}` instead of using `begin/end`. Some things are simply intuitive, fast to type and easy to read. Not to talk about the choice of the `auto` keyword instead of `var` which is what the rest of the world uses for similar pursposes... Anyway, I don't like writing C++ without using sth like MFC or Qt. I simply don't like it. I can deal with `auto` instead of `var` and other stuff done differently from the rest of the world, but underscores and 3-letter functions are not to my taste. – NoOne Nov 05 '15 at 18:04
  • 1
    @NoOne: As I said, I totally get that you are more comfortable with CamelCase. – Deduplicator Nov 05 '15 at 18:19
  • As an aside, QT has phased out (or is still doing so) most parts which duplicate the standard library. They will probably retain their own containers to avoid depending on any specific standard library implementation and their choices. – Deduplicator Oct 01 '18 at 13:05
4

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

zxcdw
  • 5,075
  • 2
  • 29
  • 31
  • 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 '12 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 '12 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 '12 at 09: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 '12 at 13:13
3

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.

Community
  • 1
Martin Ba
  • 7,578
  • 7
  • 34
  • 56