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.
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.
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 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 cross compiled an open-source library (C++ based) using my G++ cross compiler. I am now trying to use the outputted .a files in my C based application that is built using my GCC compiler... Is that possible?
Yes. Ensure that all functions you want to use are extern "C" and that you only use basic types on the functions you want to use.
If you use the same version GCC as you use G++ it should definitely not be any problem. Cross-version should be ok, but may have very minor incompatibilities. New GCC (3.0+) conform to the Itanium ABI so they'll be fine; they have a binary agreement on how to exchange & format data.
You will need to ensure that the C++ functions called from the C code are declared extern "C" and that their interfaces use only types that can be handled by C (simple types, opaque pointers, etc).
You will probably also need to link the application with the C++ compiler, rather than the C compiler, to ensure that the correct initializations are done for the C++ library. The C++ compiler used for the linking must be 'the same' as the one used to generate the library. That means either the same version of the C++ compiler or a compatible version of it. It usually means that you cannot link with CompilerA (from Vendor A) if the library was produced by CompilerB (from Vendor B); the C++ runtime conventions are such that different compilers (deliberately) use different schemes for supporting different features of C++.
You can link a C application to a c++ library,
BUT you can only include header files containing valid C -- not C++ -- code,
AND any c++ functions you call must have been declared with the extern "C" declaration.
The answer to your question is "yes" but as others have pointed out, there are some considerations, hazards & limitations to what you can do & how you do it.
Just recently in the course of covering this same topic with a client, I came across an article with a pretty good treatment of the topic. The article discusses things like calling C code from C++ code, calling C++ code from C code, linker considerations, function wrappers, exceptions, linkage specifications, and accessing C++ classes from C, etc.
Article: Mixing C and C++ Code in the Same Program
If the C++ library has C++ interfaces you cannot use them directly, you will have to create wrappers that are compiled as C++ but which have extern "C" linkage. The complexity of such wrappers will depend on the natuire of the interfaces, use of C++-only features such as classes, and function/operator overloading will require work to map an OO interface to a procedural one.
The easiest, least-hassle method to do this, assuming your C code is reasonably sane, is to simply build your C application with g++.
Remember, good C code almost always builds in a C++ compiler. Then there are no special considerations, no extern "C" statements to add, no ABI issues, etc, and you can easily use the C++ library to its fullest, regardless of how its functions are declared.
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.