Reason for not using the STL? [duplicate]

This question already has answers here: 开发者_StackOverflow社区 Closed 11 years ago.

Possible Duplicate:

To STL or !STL, that is the question

Are there cases where one should avoid the use of the C++ STL in his / her project?

---

When you choose to use a framework like Qt you might consider using lists, vectors, etc from Qt rather that the STL. Not using STL in this case saves you from having to convert from STL to the Qt equivalents when you need to use them in your GUI.

This is debatable and not everyone wants to use everything from Qt

from http://doc.qt.nokia.com/latest/containers.html

These container classes are designed to be lighter, safer, and easier to use than the STL containers. If you are unfamiliar with the STL, or prefer to do things the "Qt way", you can use these classes instead of the STL classes.

---

If you cannot use RTTI and/or exceptions, you might experience that parts of STL won't work. This is the case e.g. for native Android apps. So if it doesn't give you what you need, it's a reason not to use it!

---

Not really. There's no excuse to ban the use of an entire library- unless that lib only serves one function, which is not the case with the Standard library. The provided facilities should be evaluated on a per-function basis- for example, you may well argue that you need a container that performs a more specific purpose than vector, but that is no excuse to ban the use of deque, iostream or for_each too.

More importantly, code generated via template will not be more bloated than the equivalent code written by hand. You won't save code bloat by refusing to use std::vector and then writing your equivalent vector for float and double. Especially in 2011, the size of an executable is pretty meaningless compared to the sizes of other things like media in the vast, vast majority of situations.

---

If you care a lot about executable size, then you might want to avoid using STL in your program.

For example, uTorrent doesn't use STL and that is one reason why it's so small.

Since STL does rely on templates a lot (it is Standard TEMPLATE Library, after all), many times you use templates, the compiler has to generate extra code for every type you use when dealing with STL.

This is compile time polymorphism and will increase your executable size the more you use it.

If you exclude STL from your project (and use templates sparingly or not at all), your code size will get smaller. Note that it won't necessarily be faster.

Also note that I'm not talking about a program's memory usage during execution, since that will depend on how many objects your allocating during your app's lifetime.

I'm talking about your binary's executable.

If you want an example, note that a simple Hello world program, when compiled, might be bigger than a cleverly code demo which can include an entire 3D engine (run time generated) in a very small executable.

---

Some info regarding uTorrent's size:

Official FAQ (from 2008), this question doesn't appear in recent FAQ.

How was uTorrent programmed to be so efficient?

Second post regarding this.

Third post regarding this.

Note that, even though uTorrent is >300kb and is compressed with UPX, it is still really small when you take into account what it's capable of doing.

---

I would say that there may be occasions where you do not use a particular feature of STL in your project for a given circumstance because you can custom write it better for your needs. STL collections are generic by nature.

You might want in your code:

• Lock-free containers that are thread-safe. (STL ones are not).
• A string class that is immutable by nature and copies the actual data "by reference" (with some mechanism).
• An efficient string-building class that is not ostringstream (not part of STL anyway but you may mean all the standard library)
• algorithms that use Map and Reduce (not to be confused with std::map. Map and Reduce is a way to iterate over a collection using multiple threads or processes, possibly even distributed on different machines).

Hey, look, so much of boost was written because what the Standard Library provided at the time did not really address the needs of the programmer and thus provided alternatives.

I am not sure if this is what you meant or if you particular meant STL should be "banned" at all times (eg device driver programming where templates are considered bloaty even though that is not always the case).

---

If you are working to particular standards that forbid it.

For example, the MISRA C/C++ guidelines are aimed at automotive and embedded systems and forbid using dynamic memory allocation, so you might choose to avoid STL containers altogether.

Note: The MISRA guideline is just an example of a standard that might influence your choice to use STL. That particular guideline doesn't rule out using all of the STL. But (I believe) it rules out using STL containers as they rely on runtime allocation of memory.

---

It can increase executable size. if you're running on an embedded platform you may wish to exclude the STL.

---

When you use something like the Qt library that implements identical functionality you may not need the STL. May depend on other needs, like performance.

---

The only reason is if you are working on embedded systems with low memory, or if your project coding guidelines explicitly forbid STL.

I can't other reasonable reason to manually roll your own incompatible, bug ridden implementation of some of the features on STL.

---

TR18015 deals with some of the limitation of the STL. It looks at it from a different angle - what compilers could do better - but still is an interesting (if in-depth) read.

I'd be careful in general with microprocessors and small embedded systems. First, compiler optimizations are not up to what you know from desktops, and you run into hardware limits much sooner.

Having said that, it depends a lot on the libraries you use. I/O streams are notoriously slow (and require a careful implementation to not be), whereas std::vector is merely a thin wrapper.