What's the Difference Between "Stl" and "C++ Standard Library"

What's the difference between STL and C++ Standard Library?

The "STL" was written by Alexander Stepanov in the days long before C++ was standardised. C++ existed through the 80s, but what we now call "C++" is the language standardised in ISO/IEC 14882:2014 (and earlier versions, such as ISO/IEC 14882:2011).

The STL was already widely used as a library for C++, giving programmers access to containers, iterators and algorithms. When the standardisation happened, the language committee designed parts of the C++ Standard Library (which is part of the language standard) to very closely match the STL.

Over the years, many people — including prominent book authors, and various websites — have continued to refer to the C++ Standard Library as "the STL", despite the fact that the two entities are separate and that there are some differences. These differences are even more pronounced in the upcoming new C++ standard, which includes various features and significantly alters some classes.

The original STL is now often called "an implementation of the C++ Standard Template Library" (rather backwards to actual history!), in the same way that your Microsoft Visual Studio or GCC ships an implementation of the C++ Standard Library. But the "Standard Template Library" and the "Standard Library" are not the same thing.

The battle is about whether the current Standard Library should be called "the STL" in whole or in part, and/or whether it matters what it's called.

For "STL"

There is a school of thought that says that everybody knows now that "STL" means the standard library, just as everybody now knows that "C++" is the ISO-standardised language.

It also includes those who believe that it doesn't really matter as long as all parties understand what is being talked about.

It's a term made even more prevalent by the nature of the beast, much of which makes heavy use of the C++ feature known as "templates".

For "C++ Standard Library" (or stdlib)

However, there is another school of thought — to which I subscribe — that says that this is confusing. People learning C++ for the first time do not know this distinction, and may not notice small language differences.

The author of that article has numerous times encountered people who believe that the entire C++ Standard Library is the STL, including features that were never part of the STL itself. Most vocal proponents of "the STL", in contrast, know exactly what they mean by it and refuse to believe that not everybody "gets it". Clearly, the term's usage is not uniform.

In addition, there are some STL-like libraries that are in fact implementations of the original STL, not the C++ Standard Library. Until recently, STLPort was one of them (and even there, the confusion abounds!).

Further, the C++ Standard does not contain the text "STL" anywhere, and some people habitually employ phrases like "the STL is included in the C++ Standard Library", which is plain incorrect.

It's my belief that continuing to propagate the usage of the term in this way will just lead to the misunderstanding going on forever. Alas, it may be entirely counter-productive to attempt to change things, even if it's supposed to be for the better. We may just be stuck with double-meanings forever.

Conclusion

I appreciate that this post has been a little biased: I wrote the article you linked to. :) Anyway, I hope this helps to explain the battle a bit better.

Update 13/04/2011

Here are three perfect examples of someone who is using "the STL" to refer to the entire C++ Standard Library. It continues to baffle me that so many people swear blind that nobody ever does this, when it's plain to see almost on a daily basis.

What is the difference between the standard library and the standard template library?

The Standard Template Library (STL) is a library of containers, iterators, algorithms, and function objects, that was created by Alexander Stepanov; the SGI website has the canonical implementation and documentation.

The standard library is the library that is part of C++; it includes most of the Standard Template Library (STL).

In common usage, "STL" is also used to refer to the parts of the C++ standard library that come from or are derived from the actual SGI STL. For example, people often use "STL" to refer to std::vector and the rest of the containers in the C++ standard library, since they originated in the SGI STL.

Is there a clean separating definition between STL and C++ Standard Library? [duplicate]

STL has evolved into C++ Standard Library, it contained containers, iterators and algorithms but not streams. It is better not to use term "STL" it is the name of the old library.

What is the difference between standard library implementations in C++?

Basically any definition of every container is implementation specific. The Standard only dictates the declaration and the expected behavior, the side effects, and the conditions.

Example from §21.4.2:

basic_string(const basic_string& str,
               size_type pos, size_type n = npos,
               const Allocator& a = Allocator()); 

Requires: pos <= str.size()

Throws: out_of_range if pos > str.size().

Effects: Constructs an object of class basic_string and determines the effective length rlen of the initial string value as the smaller of n and str.size() - pos, as indicated in Table 65.

As you can see, the Standard also says what the constructor of std::basic_string does, it doesn't say how it should be implemented. It also defines the signature that should be used. The actual implementation vary across compiler vendors - gcc and clang have different implementations, although they are for the same platform, but the constructor do the same thing.

You don't need to worry about the implementations (well, technically, you do - some implementations don't implement everything, but that's rare), as they all (should) do everything documented in the standard.

What's the difference between C/C++ Library and STL C++ Library in XCode?

A statically linked library cannot be loaded at run-time but must be incorporated into your binary file when you link your executable. This means that all entry points to the code in the statically linked library are well defined and their addresses will not change relative to the start of your executable code (thus "static").

With dynamically loaded libraries, there is no way of knowing where the code will be, so when the library is loaded at run-time, a certain amount of performance overhead is necessary to "bind" the loaded code. Essentially, the linking is deferred to run-time, which is why it is also sometimes known as "late binding".

Which you choose to implement depends on your usage requirements. If you want a self-contained executable that the user can simply drag and drop into his applications folder without having to worry about dependencies, statically linking your libraries may be the way to go.

But for larger scaled projects, in apps that provide a ton of functionality, it may be prohibitive and unnecessary to load all the functionality at once. Providing a set of dynamically loadable libraries can both save memory and shorten start-up time. Then, as the user accesses features, the relevant code is loaded, and possibly features that haven't been used in a while can be unloaded.

Additionally, if you make changes to the code, you might be able to simply redistribute the one or two libraries rather than having to re-compile and re-link and re-distribute the entire executable. And need I mention the prospect of plugins?

The differences between the two templates above are subtle. Both compile C according to the GNU99 standard. But the C/C++ Library template sets up xcode to compile C++ according to the C++/GNU++0x "standard". C++/GNU++0x was later officially published as C++/GNU++11 in 2011. Both templates default to using libc++, but the STL C++ Template allows you to select to link against the older libstdc++ instead. Why would you do this? If your code links against libc++ but you are also linking against other libraries that reference libstdc++, and you run across conflicting symbols, you might be able to resolve this by linking against libstdc++ instead. The STL C++ Library template also allows you to request that the compiler stick to the C++11 standard, excluding the GNU++11 extensions, or go back to C++/GNU++98 (if you need to compile legacy code, for example).

C++ standard container and STL container in c++

Nothing in the C++ Standard Library "belongs" to the STL. STL is a different library that only influenced many parts in the C++ Standard Library. From the tag wiki:

[STL] is a C++ library of generic containers, iterators, algorithms,
and function objects. When C++ was standardised, large parts of the
STL were adopted into the Standard Library, […]

However, many people refer to the C++ Standard Library as the Standard Template Library, which is not entirely correct. I'm guessing that if you're not allowed to use the STL, they actually mean that you're not allowed to use the C++ Standard Library. But you'd have to ask them to know what they really mean.

For more information, see What's the difference between "STL" and "C++ Standard Library"?

How do I implement this type of OOP structure?

Interface Car
{
void Drive(int miles);
}

class Honda : Car
{
...
}
class Toyota : Car
{
...
}

C++: is std magically there? always?

Yes, notwithstanding special allowances for freestanding implementations which are permitted to provide only a subset, the C++ standard library must ship with every C++ compiler as it is part of the language specification. (What started out as an extension to C++ was originally called the standard template library but now a better term is the C++ standard library.)

The C++ standard library is extremely well specified - you always need to include various header files to bring in standard library components. The headers you need do not change from compiler to compiler. In this respect it is machine independent.

As the standard evolves the philosophy is to minimise compatibility breaks but there have been some: e.g. the redefinition of the auto keyword in C++11, and the deprecation of std::auto_ptr from that standard onwards.

Most components are indeed inside the reserved namespace std - some functions are not for legacy reasons. Finally it's better to use std:: explicitly rather than to bring in the entire std namespace into the global one by using

using namespace std;

else you render your code vulnerable to namespace ambiguities.

---

Related Topics