Libraries and their use

I am a complete newbie but have managed to start learning C++ and am managing quite well using 'Exploring C++ by Ray Lischner.
Using Code::Blocks I type in my listing and run it and have had success; I have even managed to write small programs of my very own.
However I cannot get my head round libraries and in particular where they are stored and how you know what is in each and suchlike.
Can anyone reccomend a book which will explain libraries, and especially the differences between say iostream and iostream.h
Sorry if this is really basic (sic) but then so is my level of understanding.

No, problem let's just get some terminology down. First, Code::Blocks is an IDE, not a compiler. Take a read through What is a compiler? It should answer most of those questions for you. As for documentation, your compilers documentation is a great place to start to see what is available. Also there are many online resources such as the reference page of C++.com that are readily available.

Originally Posted by JayCee++

However I cannot get my head round libraries and in particular where they are stored

Libraries are compiled executable files. Where they are stored depends on your OS. They may be static or dynamic, aka. shared.

When you compile your own programs, any static libraries it needs are compiled right into it by the linker. Ie, the linker finds the library and copies it in. On most modern OS's, this is considered inefficient and wasteful, so instead of linking in static libraries, your exe is linked to a shared library. Then, at runtime, the dynamic linker manages the relationship between your program and the shared libraries it is linked to.

The source for C/C++ libraries are normal looking code, defining functions, types, classes, etc, but usually without a main(), because the library does not do anything by itself. It just provides functions, types, classes, etc.

and how you know what is in each and suchlike.

That's what the header files are for; they contain function prototypes, type declarations, etc. The compiler needs that. As for the programmer, you can read the header (where they are depends on the system; on linux mostly /usr/include), but hopefully the library also has some more user friendly documentation.

A library can have more than one header file. The C++ standard library could be organized a lot of different ways as determined by the OS design, but (AFAIK) it is usually just one big shared executable file (including the STL...?). Most of the time you are only using a subset of the available features, and you include the appropriate headers, eg:

Code:

#include <iostream>
#include <string>

Those are headers. There is not actually a "iostream" library, it is part of the C++ standard library. There's just the iostream header.

You might want to read this thread from a few days ago too:

header files

Thanks Andrew and MK27, you have served to lighten my darkness considerably.

I have bookmarked the reference detailing the C++ Library for future reference.

This will probably sound simplistic but am I correct in assuming that somewhere, it shouldn'e really matter to me, inside my compiler I have a copy of the C++ Standard Library and when I use an 'include' statemant that is just telling the compiler to use a particlar part of that library.

In fact much like I used to use libraries in BASIC, but I knew where they were and often had written them myself anyway.

Onwards and upwards, it will slowly sink in..............

Originally Posted by JayCee++

This will probably sound simplistic but am I correct in assuming that somewhere, it shouldn'e really matter to me, inside my compiler I have a copy of the C++ Standard Library

No, it is not inside the compiler, because it is used by a lot of different programs concurrently. It's loaded into RAM when it is first required. On linux, if you type:

lsof | grep stdc++

You'll get a list of programs currently using the library and the path to its location.

However, compilers and the standard library are very intimately related. I believe this generally means a normal compiler will only work with the standard library it was specifically built for (as in, the actual binary implementation, not "the C++ standard library" in general). Someone else may know more details about that.

and when I use an 'include' statemant that is just telling the compiler to use a particlar part of that library.

It's actually not telling it to use anything, it is just providing it with information so that it can use some part of the library properly if it needs to. Have at look at my post in that "headers" thread.

In fact much like I used to use libraries in BASIC, but I knew where they were and often had written them myself anyway.

This is a common practice in C/C++ too, I am sure you will get there soon enough. You can compile several source files together, only one of which has a main(); the others, transitionally, are compiled into object files which are like static libraries, then they are compiled into your exe. You can also compile a source file by itself as a shared/dynamic library, write a header for it, include that header in another program, and link to your shared library. Exactly how you do that is system/compiler dependent.

Thanks for the extra clarification MK27 - I think we are both on the same page of the hymnsheet now even though we may not be in tune exactly!

Originally Posted by AndrewHunter

No, problem let's just get some terminology down. First, Code::Blocks is an IDE, not a compiler. Take a read through What is a compiler? ...

Can this be rewritten

Code::Blocks and MINGW Our recommended free compiler setup! Code::Blocks is also available on Linux.

To something like this

MINGW compiler with Code::Blocks IDE, Our recommended free compiler setup! Code::Blocks is also available on Linux.

or this

Code::Blocks IDE with MINGW Compiler, Our recommended free compiler setup! Code::Blocks is also available on Linux.

Tim S.

Originally Posted by stahta01

Can this be rewritten ....

Disregard, I see what you mean. Yes I think one of those options would be better.