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.
I understand that the prototypes of the functions are in the respective header files. The declarations of standard functions are in the standard library and that is why we use the term "using namespace std". But where are the declarations of non-standard functions stored?
The standard library does not have to be implemented as header files.
The C++ standard dicates what happens when you #include <vector>. It does not require that vector be a header file on your system; it could be implemented as a compiler intrinsic that introduces certain symbols and types.
It dictates what happens when you interact with those symbols and types.
It is usually easy to do this as a header file; but there are some C++ features in std that cannot be implemented in C++. Usually the "surface" interaction is done in C++, but they then fall back on magic compiler intrinsics.
Much of std can exist and does exist as pure header files. Other parts of it are usually compiled into libraries, often mostly written in C or C++. They interact with operating system libraries, which are also mostly written in C (and sometimes C++ and other languages), which in turn talk to hardware specific code written in a mixture of C and assembly.
The "runtime" library can be dynamically or statically linked to your output, and acts as a kind of "glue" between what C++ requires and what the specific OS provides.
Other libraries can exist. Their header files are stored in a compiler-determined way and searched for in a compiler-determined way. Linking of their libraries, dynamically or statically, is also done in a compiler-determined way, as is where said libraries exist.
They can be written in many languages, so long as they export an interface that matches the ABI that the compiler expects.
I am new in the field of Linux system programming.I currently program in C and want to switch to c++.
Can we use all the functions defined in POSIX C libraries in c++ without any change ?
In principle you should be able to use any C API from C++; the language includes features to facilitate it, and most C library authors are aware that people want to do this and will take the appropriate steps. For the system programming interfaces specified by POSIX, C++ compatibility is an explicit design goal.
However, you may still encounter problems. In my experience, the most common problems are:
C API headers often dump hundreds of symbols into the global namespace. Some of those symbols may conflict with C++ library symbols, which will get you in trouble if you using namespace std (but you weren't doing that, right?)
C API headers often make heavy use of macros, including macro names that, yep, might conflict with C++ library symbols; std:: won't save you there.
Compiling your program in a strict conformance mode (e.g. -std=c++11 -D_XOPEN_SOURCE=700) may expose bugs in system headers. This is more likely to happen with C++ than C.
A small handful of the POSIX APIs have abnormal control-flow behavior that may interact poorly with C++ exceptions and destructors, depending on how thorough your C library implementor was about avoiding the problem. setjmp and longjmp are obviously a concern here (has anyone done a C library that implements those on top of DWARF-style exception handling?) but so are fork, setcontext and friends, pthread_cancel, pthread_cleanup_push, and probably a few others I can't remember off the top of my head. (I recall a giant, ultimately inconclusive argument between Ulrich Drepper and the GCC C++ guys back in 2004 or so about exactly how pthread_cancel should behave in the presence of destructors.)
If you go beyond POSIX, you may also have problems with:
Headers that don't bother to wrap all the declarations in an extern "C" block when compiled as C++, which means all the function names get mangled when they shouldn't have been, and the link fails.
Headers that don't even bother to stick to the intersection of C and C++. In the worst case, this can cause failures that don't manifest until the program is run. The most common instances of this are:
Blithely using some C++ keyword as a declared-name (e.g. int template;)
Assuming that void * is assignment compatible with other pointer types (e.g. that it is not necessary to cast the result of malloc)
Assuming that struct foo; does not define a typedef-name foo
Note that the headers specified by POSIX frequently contain system-specific extensions that have not been as carefully thought out as the POSIX interfaces themselves.
"Can we use all the functions defined in POSIX C libraries in c++ without any change ?"
Of course you can. Any c-style API can be used seamlessly in c++.
I have previously written C++ code that #includes Unix and Linux API headers and these programs have produced the expected behavior. That said, I don't know if this can be relied on. It's possible that incompatibilities between C and C++ could cause valid C headers to act in unexpected ways when used by C++ programs.
Can Unix and Linux API headers reliably be used by code that will be compiled as C++?
Is this a goal of the authors of those headers? Or are those headers only intended to be valid C?
Are there any known pitfalls when doing this?
Obviously the Unix and Linux distributions are numerous and I don't expect an answer to address every distribution one by one. My expectation is that the same answer will apply to almost all distributions of Unix and Linux and exceptions will prove the rule. If this assumption is wrong, an explanation of that would also be a valid answer.
By Unix headers I mean these:
http://www.unix.org/version3/apis/headers.html
By Linux headers I mean the headers provided by Linux distributions usually as a package named "linux-headers" that allow programs to interact with the Linux kernel. For example, this Debian package:
https://packages.debian.org/wheezy/kernel/linux-headers-3.2.0-4-amd64
I realize the Unix link is only a specification and that each Linux distribution is different but again I suspect it's reasonable to ask this question for most distributions. If that's not true then correct me.
Edit I only mean to refer to headers used by user space programs.
C standard headers like <stdio.h>, <stdlib.h>, and so forth are specified in Appendix D of the C++ standard, which states:
These are deprecated features, where deprecated is defined as:
Normative for the current edition of the Standard, but not guaranteed
to be part of the Standard in future revisions.
The non-deprecated C++ versions of the C standard headers have names like <cstdio>, <cstdlib>, etc., and they technically put their definitions into the std (not global) namespace. So, to be 100% compliant with the non-deprecated part of the C++ spec, you need to write something like this:
#include <cstdio>
int main() {
std::printf("Hello, world!\n");
}
That said, to my knowledge, no existing implementation actually forces you to do this, and in my opinion it is unlikely any ever will. So in practice, you can safely use C standard headers in C++ without much concern.
Also, if you are on (e.g.) a POSIX system, you can generally use POSIX functionality from C++ equally safely. Certainly nobody is going to deliberately break any of this because users would revolt.
However, accidental breakage is conceivable when mixing paradigms. If both the platform and the language standard provide some feature, you should use one or the other but not both. In particular, I would not mix POSIX threading and synchronization mechanisms with standard C++11 threading and synchronization mechanisms, because it is easy to imagine an optimizer knowing too much about the latter and generating code incompatible with the former.
[Update, to elaborate somewhat]
<unistd.h> is an example of what I mean about platform-dependent functionality. It will generally work fine from C++, and neither the library nor the compiler developers will break it gratuitiously because that would be too annoying. So go ahead and call getpid() or pipe() or whatever.
But be aware that mixing paradigms raises all sorts of questions. To name just a few off the top of my head:
Can you call new from a signal handler?
Can you use dup2 onto descriptor 0 to redirect cin?
What POSIX functions can you call safely during static initialization (i.e. before main executes)?
These questions and others like them are not addressed by any spec. The answers depend on your specific implementation and could change between releases.
Having said all that... Just about every non-trivial C++ program relies on platform-specific functionality exposed by some C interface. So what you are describing will work fine in practice provided you (a) have some idea what is going on "under the hood"; (b) have reasonable expectations; and (c) do not attempt to mix standard and platform-specific paradigms.
1) Yes: "standard headers" are standard. You can safely use them regardless of platform.
2) Yes: you can mix C headers (e.g. <stdio.h>) with C++ headers (e.g. <iostream>) in the same C++ translation unit.
3) NO: you should NOT use linux kernel headers in a user mode program, nor vice versa.
Linux kernel headers are intended for kernel-mode drivers, not for "normal", user space applications.
Here is a bit more information:
https://unix.stackexchange.com/questions/27042/what-does-a-kernel-source-tree-contain-is-this-related-to-linux-kernel-headers
http://kernelnewbies.org/KernelHeaders
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.