So apparently STL is known as standard template library, which includes common data structures, classes, functions, or methods. However, the STL is not built into C++ language even though it holds the code to use such common things in the C++ language? I thought all these common data structures and methods were built into C++ language itself, but we must keep including the preprocessor directives to access them. Also, is there one preprocessor directive for all of the STL? Why have separate preprocessor directives that built up STL collectively. Should not the STL be represented by one thing?
The STL is the name of a software library, developed originally by Alexander Stepanov, and proposed for consideration by the C++ standardisation committee in 1993.
During the standardisation process, which eventually resulted in the first C++ standard being ratified in 1998, the specification of the library evolved. The C++ standard specifies the C++ standard library.
Because of this history, the STL influenced the specification of the C++ standard library. During the standardisation process before 1998, the STL was was evolved and extended. In 1994, this work resulted in a proposal for a C++ standard library by Alexander Stepanov and Meng Lee being voted and incorporated into the (then) draft C++ standard.
Technically, it is possible to distinguish between the C++ language (rules of syntax, semantics, etc) and the C++ standard library (which provides a set of types and functions that build on and support the language). A lot of the C++ standard library can be implemented in the C++ language (e.g. templated parts of the library, such as standard algorithms, which originated in STL). Some elements (e.g. the specification of the range of integral types represented by the templated std::numeric_limits) are implementation-defined. Some parts cannot be implemented in C++ at all (e.g. at some level they access "compiler magic", or use facilities of the host system (OS-specific API, machine instructions, etc).
There is not a single preprocessor directive for the C++ standard library, and never was for the STL. The philosophy is that code only accesses functionality it needs (e.g. if doing console-based I/O, it includes <iostream> but doesn't need to include <numeric> (which provides common math functions)). Practically, with most implementations, including parts of the standard library that are not needed by a program, tends to increase the time and resources needed for preprocessing and subsequent phases of translation (parsing the contents of the headers), and therefore increases build times by a substantial amount. Since significant projects can have build-from-scratch times measured in weeks or months, and using "include everything headers" can easily increase build times by orders of magnitude, it is usually considered good practice to avoid them.
The "Standard Template Library" is no more. It's the "Standard Library" now. STL was from the SGI era and has been significantly reworked and developed since then.
The reason it's broken up into various components instead of one gigantic #include file is because processing these files comes with a cost, and it can also pollute your root namespace if you're using namespace std.
C++, like C, requires inclusion of header files for the tools that you're using, nothing is supplied automatically. This isn't all that unusual, other languages force you to require or import or use other code which serves the same purpose.
Now the Standard Library is not part of the C++ language per-se, the language does not require using it, but it is an expected feature of any standard-compliant C++ compiler and the Standard Library has been improved in conjunction with the language through each major release. It's not built into the language, but it is built into the compiler, if you care for such distinctions. It'd also something that makes C++ far more useful than having just the core language.
So the Standard Library is the baseline for a C++ compiler. Many developers choose to go beyond that using things like Boost, where Boost itself is an unofficial standard library of sorts. Many features from Boost have been reworked and absorbed into the Standard Library, a trend that's likely to continue.
You can make an omni-include file that includes everything if you prefer, but you'll probably see much, much slower build times. The entire library is a considerable amount of header information to process.
So apparently STL is known as standard template library
Yes, but STL is nowadays a misnomer. It is best to call it the standard library.
However, the STL is not built into C++ language even though it holds the code to use such common things in the C++ language?
The standard library is part of the ISO C++ language.
Even for freestanding implementations (e.g. without an operating system), the standard requires implementing a fair amount of headers and things intended to support the language.
I thought all these common data structures and methods were built into C++ language itself
For hosted implementations (the ones you usually deal with unless you work on things like embedded), they are!
but we must keep including the preprocessor directives to access them.
That does not mean they are not part of the language, just that you need to include the headers like for any other library.
The language could have an "auto-detection" feature for things in the std namespace (and sometimes compilers have one to suggest you things on errors), but it is not the case.
Also, is there one preprocessor directive for all of the STL?
No, but that is not usually a problem: you can make one if you really want that (although it is usually best to just declare whatever you need in each translation unit).
Why have separate preprocessor directives that built up STL collectively. Should not the STL be represented by one thing?
The language could have specified such a thing (some languages have a "prelude" of sorts), but currently that isn't the case and you need to be explicit.
Per Wikipedia
In the C++ programming language, the C++ Standard Library is a collection of classes and functions, which are written in the core language and part of the C++ ISO Standard itself.
Related
Is C++ Standard Template Library (STL) on Windows different than the one on Linux OR any other Platform? Are the headers of STL differ with platform as well OR is STL just a header library and its implementation in CRT?
We know that compiler differ with platform and also the C Runtime Library differ with Platform. Going by this is it true that even Standard Template Library (STL) differ with platform?
Please clarify this doubt.
Also, what is the name of the C++ STL on windows and whats on Linux?
I have been trying to understand this by going various articles online and trying to frame a single workflow in my mind to understand the terms better.
The specification of the C++ Standard Library is not contingent on any particular platform or compiler, although it does depend on the target C++ standard, and its behaviour is dependent function on various properties of a platform.
But the implementation of the C++ Standard Library is extremely dependent on the compiler and operating system. Some of the C++ Standard Library can even hardcoded into compilers.
But you use it in the same way. E.g. for std::cout and std::cin you should always write #include <iostream> as that's what the documentation says you're supposed to do. The names of header files can vary between implementations, but the ones you are supposed to use directly never differ.
This is why it's a good idea not to rely on #includes being available implicitly via other headers, or by using fancy non-standard #includes like <bits/...>. If you do so then you are not writing portable C++.
C++ was designed for abstract hardware but Standard C++ Library implementations differ, yes. Library vendors are required to follow the C++ Standard rules but are free to provide their implementation where allowed (the implementation defined wording in the standard). Headers also differ.
When the C++ committee publish a new feature that will be part of the standard library in the next standard of the language, do they also release some source code or some kind of guidance on how to implement that feature?
Let's take unique_ptr as an example. The language committee just defines an interface for that class template and let the compiler vendor implement it as it wants? How exactly does this process of implementation of the standard library features occur?
Can anyone implement parts of the standard library for a platform that doesn't have support for them yet? Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that? Where should I look for information? If I decide to open source my project, can I do that? Will I need to follow exactly what the standard says, or I can write a non-compliant version?
Usually,
every new library feature goes through a proposal.
If the proposal makes it to the C++ committee's Library Evolution Working Group, it goes through a series of iterations (a "tough ground" as I am aware).
It undergoes a series of refinement process as described here
Should it require a (TS) Technical Specification (since C++11), it goes there to be baked. Take for example, the #include <filesystem> was in a Filesystem TS prior to C++17.
One thing I believe the committee likes, is an implementation experience.
More information can be found on the ISOCpp site
Well, as to the implementation:
There are quite a number of "library features" that cannot be implemented purely as a library. they require compiler support. And in these case, compilers provides "intrinsic" that you could hook on to. Take for example, clang provides intrinsics for certain type_traits
Most library features have some implementation experience, mostly from the Boost libraries.
You could actually look into the source code for the default standard library that ships with your compiler:
libc++ for Clang
libstdc++ for GCC
Sadly most of the implementations use a whole bunch of underscores. Mostly because they are reserved for use by the "Standard Library".
Can anyone implement parts of the standard library for a platform that doesn't have support for it yet?
Yes, you can, so far your compiler supports that platform, and the platform or Operating System provides usable API. For example. std::cout, elements of std::ifstream, and so much more requires platform specific support.
Let say I would like to implement some cool features of the C++ standard library to use it on a microcontroller environment. How could I do that?
You can look into the code of others and start from there. We learn from giants. Some Open Source Examples:
ETL
StandardCPlusPlus
uClib++
How could I do that? Where should I look for information?
You could check the paper that introduced the feature into the C++ library. For example, std::optional has a stand-alone implementation here which was used as a reference implementation during the proposal stages.
You could check the standard library, and do a laborious study. :-)
Search the internet. :-)
Or write it from scratch as specified by the standard
Will I need to follow exactly what the standard say or I can write a non-compliant version?
There's is no compulsion to follow what the C++ standard library specifies. That would be your "own" library.
Formally, no. As with all standards out there, C++ Standard sets the rules, and does not gives implementation. However, from the practical standpoint, it is nearly impossible to introduce a new feature into Standard Library without proposed implementation, so you often can find those attached to proposals.
As for your questions on "can you write non-compliant version", you can do whatever you want. Adoption might depend on your compliance, or might not - a super-widely adopted MSVC is known to violate C++ standard.
Typically, a new feature is not standardized, unless the committee has some solid evidence that it can be implemented, and will be useful. This very often consists of a prototype implementation in boost, a GNU library, or one of the commercial compiler vendors.
The standard itself does not contain any implementation guidance - it is purely a specification. The compiler vendors (or their subcontractors) choose how to implement that specification.
In the specific case of unique_ptr, it was adopted into the standard from boost::unique_ptr - and you can still use the latter. If you have a compiler that will compile for your microcontroller, it is almost certain that it will be able to build enough of boost to make unique_ptr work.
There is nothing stopping you from writing a non-conforming implementation (apart from the trivial point that if you sold it as being standards-conforming, and it wasn't you might get your local equivalent of Trading Standards come knocking.)
The committee does not release any reference implementations. In the early days, things got standardized and then the tool developers went away and implemented the standard. This has changed, and now the committee looks for features that have been implemented and tested before standardization.
Also major developments usually don't go directly into the standard. First they become experimental features called a Technical Specification or TS. These TS may then be incorporated into the main standard at a later date.
You are free to write you own implementation of the C++ standard library. Plum Hall has a test suite (commercial, I have no connection, but Plum Hall are very involved with C++ standardization).
I don't see any issue with not being conformant. Almost all implementations have some extensions. Just don't make any false claims, especially if you want to sell your product.
If you're interested in getting involved, this can be done via your 'National Body' (ANSI for the USA, BSI for the UK etc.). The isocpp web site has a section on standardization which would be a good starting place.
Someone brought this article to my attention that claims (I'm paraphrasing) the STL term is misused to refer to the entire C++ Standard Library instead of the parts that were taken from SGI STL.
(...) it refers to the "STL", despite the fact that very few people still use the STL (which was designed at SGI).
Parts of the C++ Standard Library were based on parts of the STL, and it is these parts that many people (including several authors and the notoriously error-ridden cplusplus.com) still refer to as "the STL". However, this is inaccurate; indeed, the C++ standard never mentions "STL", and there are content differences between the two.
(...) "STL" is rarely used to refer to the bits of the stdlib that happen to be based on the SGI STL. People think it's the entire standard library. It gets put on CVs. And it is misleading.
I hardly know anything about C++'s history so I can't judge the article's correctness. Should I refrain from using the term STL? Or is this an isolated opinion?
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.
There is no one answer that's really correct. Alexander Stepanov developed a library he called STL (working for HP at the time). That library was then proposed for inclusion in the C++ standard.
That basically "forked" development. The committee included some parts, rejected others completely, and redesigned a few (with Alexander's participation). Development of the original library was later moved to Silicon Graphics, but continued separately from the C++ standard library.
After those pieces were added to the standard library, some other parts of the standard library were modified to fit better with what was added (e.g., begin, end, rbegin and rend were added to std::string so it could be used like a container). Around the same time, most of the library (even pieces that were completely unrelated) were made into templates to accommodate different types (e.g., standard streams).
Some people also use STL as just a short form of "STandard Library".
That means when somebody uses the term "STL" they could be referring to any of about half a dozen different things. For better or worse, most people who use it seem to ignore the multiplicity of meanings, and assume that everybody else will recognize what they're referring to. This leads to many misunderstandings, and at least a few serious flame-wars that made most of the participants look foolish because they were simply talking about entirely different things.
Unfortunately, the confusion is likely to continue unabated. It's much more convenient to refer to "STL" than something like "the containers, iterators, and algorithms in the C++ standard library, but not including std::string, even though it can act like a container." Even though "C++ standard library" isn't quite as long and clumsy as that, "STL" is still a lot shorter and simpler still. Until or unless somebody invents terms that are more precise (when necessary), and just as convenient, "STL" will continue to be used and confusion will continue to result.
The term "STL" or "Standard Template Library" does not show up anywhere in the ISO 14882 C++ standard. So referring to the C++ standard library as STL is wrong. The term "C++ Standard Library" or "standard library" is what's officially used by ISO 14882:
ISO 14882 C++ Standard:
17 - Library introduction [lib.library]:
This clauses describes the contents of the C++ Standard Library, how
a well-formed C++ program makes use of
the library, and how a conforming
implementation may provide the
entities in the library.
...
STL is a library originally designed by Alexander Stepanov, independent of the C++ standard. However, some components of the C++ standard library include STL components like vector, list and algorithms like copy and swap.
But of course the C++ standard includes much more things outside the STL, so the term "C++ standard library" is more correct (and is what's actually used by the standards documents).
I've made this same argument recently, but I believe a little tolerance can be allowed. If Scott Meyers makes the same mistake, you're in good company.
From the GNU Standard C++ Library (libstdc++) FAQ:
The STL (Standard Template Library) was the inspiration for large chunks of the C++ Standard Library, but the terms are not interchangeable and they don't mean the same thing. The C++ Standard Library includes lots of things that didn't come from the STL, and some of them aren't even templates, such as std::locale and std::thread.
Libstdc++-v3 incorporates a lot of code from the SGI STL (the final merge was from release
3.3). The code in libstdc++ contains many fixes and changes compared to the original SGI code.
In particular, string is not from SGI and makes no use of their "rope" class (although that is included as an optional extension), neither is valarray nor some others. Classes like vector<> were from SGI, but have been extensively modified.
More information on the evolution of libstdc++ can be found at the API evolution and backwards compatibility documentation.
The FAQ for SGI's STL is still recommended reading.
FYI, as of March 2018 even the official STL web site www.sgi.com/tech/stl/ is gone.
In layman words: STL is part of Standard Library.
C++ Standard Library is group into:
Standard Functional Library
-I/O,
-String and character handling,
-Mathematical,
-Time, date, and localization,
-Dynamic allocation,
-Miscellaneous,
-Wide-character functions
Standard OOP and Generics Library
-The Standard C++ I/O Classes
-The String Class
-The Numeric Classes
-The STL Container Classes
-The STL Algorithms
-The STL Function Objects
-The STL Iterators
-The STL Allocators
-The Localization library
-Exception Handling Classes
-Miscellaneous Support Library
So if you are talking about STL as Standard Library, it is OK and just remember that STL implementations allow for generics and others are more specific to one type.
Please refer to https://www.tutorialspoint.com/cplusplus/cpp_standard_library.htm
C++ Standard Library includes C++ STL
The contents of the C++ standard library are:
C++ version of C language header file
C++ IO header file
C++ STL
So please don’t confuse the C++ standard library with STL.
Do libraries such as boost, STL, ACE (which often make inclusions in namespace std) contain any special kind of coding techniques which is not possible to be coded/used by a usual programmer ?
In a broader sense, do they leverage any compiler or implementation specific utilities, which is not exposed to the general programmers ?
These are all written in the same code available to everyone. However, the code is often hard to read (at least for me) because they go to great lengths to ensure the generality of the libraries. Here is the sgi implementation of the STL. Browse through it and see for yourself.
Since the standard library is part of the C++ specification, your question is not well-founded.
For example, the implementation of std::fstream (or at least, std::filebuf) must use OS-dependent interfaces. Do those count as "implementation specific utilities"?
The bottom line is that the spec does not separate out the standard library from the rest of the language. It is all just part of the language, and its facilities are available to "usual programmers".
Boost is mostly written in standard C++, but they do take advantage of platform-specific features when that can yield performance improvements, and they occasionally need compiler-dependent extensions for features. The documentation will generally mention when a feature is not available on all platforms.
I do not know about ACE.
The STL (and the others) is written in 'pure C++'. See here for a very similar question.
C, on the other hand, has many system calls (unix/Windows/etc) in its standard library files to make everything work.
The C++0x STL also uses some compiler magic to make some new language features work.
Someone brought this article to my attention that claims (I'm paraphrasing) the STL term is misused to refer to the entire C++ Standard Library instead of the parts that were taken from SGI STL.
(...) it refers to the "STL", despite the fact that very few people still use the STL (which was designed at SGI).
Parts of the C++ Standard Library were based on parts of the STL, and it is these parts that many people (including several authors and the notoriously error-ridden cplusplus.com) still refer to as "the STL". However, this is inaccurate; indeed, the C++ standard never mentions "STL", and there are content differences between the two.
(...) "STL" is rarely used to refer to the bits of the stdlib that happen to be based on the SGI STL. People think it's the entire standard library. It gets put on CVs. And it is misleading.
I hardly know anything about C++'s history so I can't judge the article's correctness. Should I refrain from using the term STL? Or is this an isolated opinion?
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.
There is no one answer that's really correct. Alexander Stepanov developed a library he called STL (working for HP at the time). That library was then proposed for inclusion in the C++ standard.
That basically "forked" development. The committee included some parts, rejected others completely, and redesigned a few (with Alexander's participation). Development of the original library was later moved to Silicon Graphics, but continued separately from the C++ standard library.
After those pieces were added to the standard library, some other parts of the standard library were modified to fit better with what was added (e.g., begin, end, rbegin and rend were added to std::string so it could be used like a container). Around the same time, most of the library (even pieces that were completely unrelated) were made into templates to accommodate different types (e.g., standard streams).
Some people also use STL as just a short form of "STandard Library".
That means when somebody uses the term "STL" they could be referring to any of about half a dozen different things. For better or worse, most people who use it seem to ignore the multiplicity of meanings, and assume that everybody else will recognize what they're referring to. This leads to many misunderstandings, and at least a few serious flame-wars that made most of the participants look foolish because they were simply talking about entirely different things.
Unfortunately, the confusion is likely to continue unabated. It's much more convenient to refer to "STL" than something like "the containers, iterators, and algorithms in the C++ standard library, but not including std::string, even though it can act like a container." Even though "C++ standard library" isn't quite as long and clumsy as that, "STL" is still a lot shorter and simpler still. Until or unless somebody invents terms that are more precise (when necessary), and just as convenient, "STL" will continue to be used and confusion will continue to result.
The term "STL" or "Standard Template Library" does not show up anywhere in the ISO 14882 C++ standard. So referring to the C++ standard library as STL is wrong. The term "C++ Standard Library" or "standard library" is what's officially used by ISO 14882:
ISO 14882 C++ Standard:
17 - Library introduction [lib.library]:
This clauses describes the contents of the C++ Standard Library, how
a well-formed C++ program makes use of
the library, and how a conforming
implementation may provide the
entities in the library.
...
STL is a library originally designed by Alexander Stepanov, independent of the C++ standard. However, some components of the C++ standard library include STL components like vector, list and algorithms like copy and swap.
But of course the C++ standard includes much more things outside the STL, so the term "C++ standard library" is more correct (and is what's actually used by the standards documents).
I've made this same argument recently, but I believe a little tolerance can be allowed. If Scott Meyers makes the same mistake, you're in good company.
From the GNU Standard C++ Library (libstdc++) FAQ:
The STL (Standard Template Library) was the inspiration for large chunks of the C++ Standard Library, but the terms are not interchangeable and they don't mean the same thing. The C++ Standard Library includes lots of things that didn't come from the STL, and some of them aren't even templates, such as std::locale and std::thread.
Libstdc++-v3 incorporates a lot of code from the SGI STL (the final merge was from release
3.3). The code in libstdc++ contains many fixes and changes compared to the original SGI code.
In particular, string is not from SGI and makes no use of their "rope" class (although that is included as an optional extension), neither is valarray nor some others. Classes like vector<> were from SGI, but have been extensively modified.
More information on the evolution of libstdc++ can be found at the API evolution and backwards compatibility documentation.
The FAQ for SGI's STL is still recommended reading.
FYI, as of March 2018 even the official STL web site www.sgi.com/tech/stl/ is gone.
In layman words: STL is part of Standard Library.
C++ Standard Library is group into:
Standard Functional Library
-I/O,
-String and character handling,
-Mathematical,
-Time, date, and localization,
-Dynamic allocation,
-Miscellaneous,
-Wide-character functions
Standard OOP and Generics Library
-The Standard C++ I/O Classes
-The String Class
-The Numeric Classes
-The STL Container Classes
-The STL Algorithms
-The STL Function Objects
-The STL Iterators
-The STL Allocators
-The Localization library
-Exception Handling Classes
-Miscellaneous Support Library
So if you are talking about STL as Standard Library, it is OK and just remember that STL implementations allow for generics and others are more specific to one type.
Please refer to https://www.tutorialspoint.com/cplusplus/cpp_standard_library.htm
C++ Standard Library includes C++ STL
The contents of the C++ standard library are:
C++ version of C language header file
C++ IO header file
C++ STL
So please don’t confuse the C++ standard library with STL.