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.
Related
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.
Must a conforming C++ Standard Library Implementation be implemented in C++?
If not, is it allowed to do magic things that are not doable in pure C++ & Standard Library & some implementation defined behaviour?
I am aware that there are parallel implementations that rely on extensions (in pre C++11 at least), but are they really conforming?
I couldn't find any requirement in the standard, but maybe my standard-fu is weak today
There is no requirement at all how the standard C++ library (or the standard C library for that matter) is implemented. All the library needs to achieve is to implement the documented and specified interface. How this is done is entirely up to the implementation. Part of standard libraries are often implemented by the compiler in some magic way and in C++2011 there are several interfaces which actually cannot be implemented using standard C++2011 language facilities! Primarily this is true for some of the traits in <type_traits> but there are other things.
Just for the reference: how C++ is implemented and what it actually really means to conform to the standard is held extremely vague. The relevant clause is 1.4 [intro.compliance]. It merely speaks about diagnostics being issued and what a program has to do, constraint to resource limitations, however.
No.
Actually, it is even prescribed by the Standard that #include <map> (for example) could simply import a pre-stored AST and not refer to a file, at all.
Not at all, only the interface needs to be C++.
I was just curious because in my homework it says that the following statement is false:
The C++ Standard Library functions and classes are not included in every C++ implementation.
I don't think that the Standard Library is included in every C++ implementation unless you add (#include) the appropriate headers, right? In that case, I think that the above statement is true, not false.
Is the statement true or false?
Looks like unfortunate overloading of the word "include".
Your C++ compiler comes with files containing the standard library. So they are "included". But they aren't #include-d, you have to write #include in your source files to get access to the standard library.
In addition, there are hosted and freestanding implementations. Here's what the Standard says:
Two kinds of implementations are defined: a hosted implementation and a freestanding implementation. For a hosted implementation, this International Standard defines the set of available libraries. A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries (17.6.1.3).
Since the statement says "every C++ implementation", and freestanding implementations do not include the entire C++ Standard Library, the statement is TRUE.
The statement is true (and your homework instructor is wrong). The standard distinguishes in 17.4.1.3 between hosted and freestanding implementations. Only the hosted implementations are required to implement the C++ standard library. The freestanding implementation is only required to have these headers:
18.1 Types <cstddef>
18.2 Implementation properties <limits>
18.3 Start and termination <cstdlib>
18.4 Dynamic memory management <new>
18.5 Type identification <typeinfo>
18.6 Exception handling <exception>
18.7 Other runtime support <cstdarg>
If the C++ implementation claims to be a conforming implementation of the C++ Standard (ISO/IEC 14882) it needs to include an implementation of both the compiler and the standard C++ library. Even for a conforming implementation the standard library doesn't have to be complete, though: there is a difference between free-standing and hosted implementations. While the former is only required to have very basic support, the latter requires that the entire implementation is provide (I think it is this way around but I keep getting confused about the terms; it may be the other way around).
That said, there are various compilers which don't ship with more than a very basic library and the basic library they ship with consists of things the compiler either has to do or the run-time absolutely need to run. They don't claim to be conforming implementations, however. You would need to combine them with a library but there are several libraries you can purchase (or download, some of them are free but the free ones seem to only work with a couple of specific compilers).
Are standard library required to be standard conformant? I've this feeling that standard library aren't standard conformant. The basis of this feeling is the error messages generated by the compiler(s). For example, sometime GCC gives error messages which starts with prefix __gxx and many others which I don't remember as of now. But seeing them gives me feeling that these are very compiler specific messages, and different compilers wouldn't be able to compile standard library provided by GCC, and vice-versa. Is it true?
The question can be asked in other words as:
Can standard library provided by one compiler be compiled with other compilers?
When we say a particular compiler is standard conformant, does it automatically mean that the stdlib which comes with it is also standard-conformant? Or it simply means that this compiler can compile standard-conformant code written by us, programmers?
Can I use standard library provided by one compiler, in my project which uses a different compiler to compile the project? Is portability same as standard-conformance?
These questions are different angles to look at the same big question. So, please help me understanding what does it exactly mean when we say compiler X is standard-conformant.
The standard library is a detail of implementation. It may not even be 'compiled' in the sense that the standard doesn't require it to consist of 'files' [headers]:
174) A header is not necessarily a source file, nor are the sequences delimited by < and > in header names necessarily valid
source file names (16.2).
The standard carefully eases the requirements on the implementation, so that the library may be 'built-in' to the compiler (a.k.a intrinsics). For example, extending the std namespace, or #defining a name used in the standard library gives you undefined behavior.
Yes, standard libraries must adhere to the standard, but there is quite a bit of flexibility in that. The standard does not require a particular implementation of the functions, and the implementation is free to add internal functions, attributes... as long as the requirements are met.
Note that there is a different concept of the library conforming with the standard and the library being implemented using only standard features.
On the particular questions below:
Can standard library provided by one compiler be compiled with other compilers?
Some will, some won't. The implementation of the standard library can use compiler intrinsics for some operations, of features present only in one platform and not others... Some STL implementations can be compiled with different compilers though, like STLPort, Dinkumware (which is also the one shipped in VS, with some VS modifications)
When we say a particular compiler is standard conformant, does it automatically mean that the stdlib which comes with it is also standard-conformant? Or it simply means that this compiler can compile standard-conformant code written by us, programmers?
It means that the library must be conformant, but again, the standard does not mandate the implementation of the library, and these can use non-standard extensions and the like, which will work in one compiler but possibly not in other compilers. Consider, for example, an implementation of shared_ptr, the reference count has to be updated atomically but there was no atomic operations on integers in the current standard, so it has to be implemented in terms of non-standard features.
Can I use standard library provided by one compiler, in my project which uses a different compiler to compile the project? Is portability same as standard-conformance?
Not necessarily.
Are standard library required to be standard conformant? I've this feeling that standard library aren't standard conformant.
By definition, an implementation must conform to the standard to be standard-conformant, yes.
Otherwise it's not an implementation of the C++ Standard Library, but of some other thing.
When we say a particular compiler is standard conformant, does it automatically mean that the stdlib which comes with it is also standard-conformant?
This would depend on the wording, wouldn't it? If the toolchain purports to include an implementation of the Standard Library, one may reasonably assume that it's compliant. That the compiler executable itself is compliant is not the same thing, unless the library implementation is built into the compiler executable.
But this is all just wordplay.
Can I use standard library provided by one compiler, in my project which uses a different compiler to compile the project? Is portability same as standard-conformance?
Of course not. Two conformant implementations may be completely incompatible with each other.
For example, sometime GCC gives error messages which starts with prefix __gxx and many others which I don't remember as of now.
That's fine. The toolchain may implement the library however it chooses, as long as the interface conforms to the standard. The standard does not say that the implementation cannot use a symbol __gxx in its work.
BTW
Though, it does say that the programmer may not use symbols with leading underscores, in some cases!
You aren't allowed ([lib.requirements]/[requirements]) to use any name which:
contains two consecutive underscores,
begins with an underscore followed by an uppercase letter
begins with an underscore and is in the global namespace
Also, in C++0x, literal suffixes that do not start with an underscore are reserved.
The user-facing API of the library should be standard; the implementation is not required to be, however. You're seeing an example of this, where the standard version of a function is replaced with an optimized variant (with a different name because sometimes the replacement is only possible in some circumstances, such as when appropriate alignment can be proven). This also means that the implementation of one compiler's standard library might not be buildable by a different compiler (which can lead to bootstrapping issues when porting, but that's another issue).
what does it exactly mean when we say compiler X is standard-conformant
It means that the compiler provides the standard library with all the requirements layed upon by the standard and that the implementation itself conformes to all requirements in the standard. The thing is, the "requirements" for the standard library are quite liberal after the general interface.
The Standard library only has to meet a minimum interface. In it's implementation it can do whatever it wants, because, well, it's the implementation, although I'm pretty sure there are some identifier restrictions and such to prevent clashes.
The Standard library implementation does not have to be portable in any way. They can be, but far from necessarily.
The standard places restrictions on the interface of the standard library, not the implementation. It goes out of its way to make it clear that standard library headers can do things user code can not... __MACRO__NAME__ is reserved for the implementation, for instance. And obviously, only the implementation can actually put all these functions and types into namespace std.
Mostly, a "portable" implementation could be written. But it would likely be less performant... as an easy example, consider the traditional implementation of the offsetof macro. It generally involves dereferencing a null pointer, which is formally undefined behavior, but because the implementation knows how its platform works, that's okay. A portable version can not do this, so it would have to actually create a new instance of the provided type to keep everything on the up and up.
Quite a few type traits in C++0x likely require compiler support, which makes a "portable" implementation somewhere between difficult and impossible. There's no standard way to analyze if an arbitrary type is POD, for instance, which is why boost::is_pod requires user support via specialization on some platforms.
There is also the consideration that a lot of the standard library is not header-only. The other bits can be written in a completely different language... so long as it all links together properly, it doesn't matter. If the runtime is implemented in Lisp, obviously it won't be C++ compliant code that can be reliably dropped into a different compiler toolchain.
Can standard library provided by one compiler be compiled with other
compilers?
Assuming that the library is standards conforming, yes (I know this is kind of chicken-and-egg).
When we say a particular compiler is standard conformant, does
it automatically mean that the stdlib
which comes with it is also
standard-conformant? Or it simply
means that this compiler can compile
standard-conformant code written by
us, programmers?
Yes, although I'm not aware of any fully confirming compiler. Note that standards conforming for us as programmers is different from the standard library. For example the implementation is allowed to use identifiers containing __ (double underscore).
Can I use standard library provided by one compiler, in my
project which uses a different
compiler to compile the project? Is
portability same as
standard-conformance?
You should be able to compile and use such a library. You almost certainly wouldn't be able to use any compiled library files (static or dynamic) file because name mangling would be different.
Each header from the C Standard
Library is included in the C++
Standard Library under a different
name, generated by removing the .h,
and adding a 'c' at the start, for
example 'time.h' becomes 'ctime'. The
only difference between these headers
and the traditional C Standard Library
headers is that where possible the
functions should be placed into the
std:: namespace (although few
compilers actually do this).
Since c functions are put into the std:: namespace,I tried :
man std::printf
but got :
No manual entry for std:printf
Any reasons?(I've installed libstdc++-doc and I've no problem with canonical c++ stuff like man std::cout)
UPDATE
The reason to say c++ is junky at least includes:
junky c++ manual
an empty c++ programe needs libstdc++,libm and libgcc_s,while c programe only needs libc.
There really is no point in documenting the C++ functions that come from standard C if they are identical and are already documented (like printf is).
The behavior of the C standard library functions is out of the control of libstdc++ developers. It relies (in this and most other C++ Standard library implementations) on the underlying platform's Libc implementation. On Linux, that's most probably glibc, on Windows, msvcrt, etc...
The point is that all these different libraries provide different and non-conforming behavior, which would have to be documented in the libstdc++ documentation, and that is impossible (no, very hard) to do and maintain. It also serves no practical purpose, as this documentation exists elsewhere.