Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 7 down vote favorite
2

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?

share|improve this question
related question – FredOverflow Aug 16 '12 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 '12 at 10:25
As for skipping stuff during debugging, see, for example: stackoverflow.com/questions/2062881/… – Martin Ba Aug 16 '12 at 11:33

5 Answers

up vote 17 down vote

  • 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 than 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 standard library used to be unsupported by Microsoft early in WinCE (IIRC iostreams only came out with Visual Studio 2005), but it was known 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++.

share|improve this answer
4  
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 9:02
1  
+1 for point #2 – Jonathan Henson Aug 16 '12 at 14:33
@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 8:29
@JanHudec: Indeed, that's why the STL parts are only required for "hosted" implementations of C++. – MSalters Aug 17 '12 at 8:37
up vote 3 down vote

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.

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
3  
Aka "don't use it when you don't have it", which makes sense, really. :) – Xeo Aug 16 '12 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 '12 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 '12 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 '12 at 8:18
up vote 2 down vote

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.

share|improve this answer
1  
This answer had a down-vote. Can the down-voter please give me a hint on how to improve it? Thanks. – Giorgio Aug 16 '12 at 12:33
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
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 8:03
@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 '12 at 8:43
show 3 more comments
up vote 0 down vote

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

share|improve this answer
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
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
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 9:13
@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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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