Core header files in c++

Question

When we want to using a function from standart c++ library we're inculding a coressponding header file. But header file is just contains the function declaration. From what implementation of this function is appear? Consider the following simple programm:

#include <stdio.h> //Here is only declaration of functions, not implementation.

int main(){
    printf("Hello world");
}

Where is implementation of this function? I don't specified that I want to compiling and linking other .cpp files.

Answer 1

The compiled code resides in libraries. The exact location and name of these libraries depends on the platform and compiler. For example, on various Unixen GCC's standard C++ library is in two versions: "/usr/lib/libstdc++.so.{version}" and "/usr/lib/libstdc++.a". On older versions of OS X, you'll find "/usr/lib/libstdc++.{version}.dylib" and "/usr/lib/libstdc++-static.a"; newer versions use libc++: "/usr/lib/libc++.{version}.dylib". (More on why there are two versions on a single sytem below.) GCC and MingW on Windows both have a libstdc++-{version}.dll, where Visual Studio has a number of libraries (e.g. msvcp110.dll, msvcprt.lib) that compose their runtime library. The dynamic libraries aren't installed as part of Windows (though they are used by so many applications, they're present on many machines) and need to be packaged and distributed with your application.

After compilation of your code (which converts your C++ code to object code) comes linking, where external symbols in your code are resolved to symbols in libraries. Some libraries (such as libstdc++) are linked to your object code by the linker by default. Other libraries can be added to the linking process. For example, if you use Boost.Thread, you'd add boost_thread-mt, boost_thread-vc80-mt or whatever the local name is to the list of libraries to link against.

The reason for the two different versions of a library is that one provides static linking, where the library's object code is copied into the linked code, and the other dynamic linking, where the symbols in your code refer to the library file, but no object code is copied. The latter has the advantage of smaller file sizes (since the code is kept in a single library, rather than duplicated in every binary that uses it). The main problem with dynamic libraries is dependency hell, where two different software packages require different, incompatible versions of a library. When stuck in dependency hell, at least one library will be the wrong version for least one software package, which thus won't work. Versioning the library filenames goes a long way towards preventing this, as multiple library versions can exist side-by-side, and the software binaries can be linked to the appropriate version.