when someone include <iostream> how does the compiler know which library to load?

Recommended Answers

All 10 Replies

That's not a library reference, that's an include file reference.

The compiler (ok, maybe the preprocessor) will search for a file of the specified name through each of the directories in the include path. It will use the first file it finds. The contents of the file it finds are 'included' as if they were actually typed in that location.

The C++ Standard (16.2):

2 A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
3 A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original directive.

i know that when i include <iostream> i include a header file not a library. That is why my question is how the compiler knows the associated library with that header.

i know that when i include <iostream> i include a header file not a library. That is why my question is how the compiler knows the associated library with that header.

So simple answer: it does not know that ;)
The compiler includes external symbol references to library function names in the generated object module. That's a linker job to assemble an executable module from all object modules and all libraries to resolve all external references in all object modules (compiled and extracted from libraries).
If you work with IDE there are default paths to all RTL libraries so IDE passes these paths to the linker (all C++ headers declare functions collected in these libraries). Sometimes you need to present additional library paths (for example, if you have used windows.h header file or other non-standard headers). You must know what libraries needed and where they located (from docs, of course)...

Microsoft C / C++ support an extension that a header file could use to add a default library to search. It is a preprocessor pragma that puts a comment record in the object files: #pragma comment( lib, "emapi" ) (where 'emapi' could be any library name). The end effect when this is encountered by the linker is to add that library to list of default libraries to search for.

It is however uncommon to see them used as if you have different library names based on any compile options, you would have to also detect the compile options to make sure you specify the correct library name.

ok guys you dont seem to understand what i ask. let's say i am compiling some c++ code with GNU compiler using unix command line. all my code file content is as follows :

#include <iostream>
using namespace std;
int main()
{
  cout << " deneme " << endl;
  return 0;
}

ok now what i ask is : how can i use cout object? how did the linker or compiler find the path to that IO library when all i do is only header inclusion?

>how did the linker or compiler find the path to that IO library when all i do is only header inclusion?
Compiling and linking are two separate stages. The header is only relevant during compilation because declarations for the names you use must be present before you use them or the compiler will fail with a syntax error. When you link, you specify which libraries you want to link with (certain standard libraries may be linked automatically). The linker then searches these libraries for the names you used in the translation unit and matches them to the definitions from one of those libraries; it throws a link error if no definition can be found.

To answer your question, the linker finds the path to the library because either the library is among the standard libraries that it searches automatically, or the path was provided as an argument when calling the linker.

The headers (include files) define the names so the compiler knows what things can be done with the name.

The compiler then goes through and genereates symbol references in the object file. For example cout << " deneme " is a call to a method something like ostream & ostream::operator << (char const *) which for an ostream puts the string into the output stream. At the object file level, it knows that it needs to resolve the method.

The linker collects the object files with all of their undefined symbols and attempts to resolve them through the list of librarys (both default and specified).

>how did the linker or compiler find the path to that IO library when all i do is only header inclusion?
Compiling and linking are two separate stages. The header is only relevant during compilation because declarations for the names you use must be present before you use them or the compiler will fail with a syntax error. When you link, you specify which libraries you want to link with (certain standard libraries may be linked automatically). The linker then searches these libraries for the names you used in the translation unit and matches them to the definitions from one of those libraries; it throws a link error if no definition can be found.

To answer your question, the linker finds the path to the library because either the library is among the standard libraries that it searches automatically, or the path was provided as an argument when calling the linker.

in short, you mean, since standart library is automatically added you dont need to explicity add standart library where std::cout resides?

>in short, you mean [...]
Yea, I guess that's close enough. :icon_rolleyes:

>standart
It's spelled standard.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.