where is the C++ standard library located?
I am curious when I wrote some C++ code to using something inside C++ standard libraries, e.g.: I use io stream:
include <iostream>
I don't need to tell IDE where to find this library (I use visual studio). How the IDE know where to find these libraries to link with my program?
Furthermore, if I want to use some third-party libraries (my understanding is I should get dll instead of source code?) How should I include these libraries for my project?
Thanks in advance.
include <iostream>
I don't need to tell IDE where to find this library (I use visual studio). How the IDE know where to find these libraries to link with my program?
Furthermore, if I want to use some third-party libraries (my understanding is I should get dll instead of source code?) How should I include these libraries for my project?
Thanks in advance.
Last edited on
| where is the C++ standard library located? |
| I don't need to tell IDE where to find this library (I use visual studio). How the IDE know where to find these libraries to link with my program? |
| How should I include these libraries for my project? |
| if I want to use some third-party libraries (my understanding is I should get dll instead of source code?) How should I include these libraries for my project? |
If a precompiled DLL is available for Windows, use it. That will save you from having to build the library.
To specify where the include files are for the library, open the property pages for your project. Under C/C++ compiler, on the General tab, the first entry is "Additional Include Directories". List there any directories you want the compiler to search in the order you want them searched. Multiple entries are separated by semicolons.
Thanks for reply.
(1) So generally standard library actually located in my computer, and when I installed the compiler, these libraries are installed too, correct?
(2) if the precompiled DLL is not available for Windows, I have to use the source code to compile to generate DLL by myself, correct?
Thanks in advance.
(1) So generally standard library actually located in my computer, and when I installed the compiler, these libraries are installed too, correct?
(2) if the precompiled DLL is not available for Windows, I have to use the source code to compile to generate DLL by myself, correct?
Thanks in advance.
1) Yes.
2) Yes, although in my experience this is uncommon. If a package is available for Windows, there is generally either a static library or a DLL that is pre-built.
2) Yes, although in my experience this is uncommon. If a package is available for Windows, there is generally either a static library or a DLL that is pre-built.
The answer given feels a little simplistic to me...
All compiled code must be somewhere.
precompiled code
All compilers in existence come with precompiled standard libraries, almost always in a number of DLLs (.dll on Windows or .so on nixen). That's more than one, mind you. (There's the C standard library, which comes in at least two parts -- the basic part and the math part. And then there's the C++ standard library, which also comes in parts.)
Anything you use from the STL introduces code your application compiles (all the templates are new things created by your application). That said, sometimes some parts can come precompiled. Say, a std::string class -- common enough that your compiler may already have it precompiled and just link it into your final executable, either statically or dynamically. On top of that, some STL code relies on stuff that is already in a precompiled library, like <chrono> does.
precompiled code is usually in DLLs that your user must have
All these things must be connected (or linked) to your final executable. Some of it can be statically linked (compiled as part of your final executable file) but much of it is in DLLs that must be present on your system.
You don't normally notice because (1) your system has those DLLs since you installed the compiler (2) your compiler uses standard system DLLs. For example, everyone who has Windows has Microsoft's standard C runtime library installed. It's part of the system. So compilers that compile for Windows will usually (not all do, but smart ones do) compile against the standard Microsoft runtime library DLLs. You give your friends an .exe file, but that .exe uses DLLs that your friends (should) already have installed on their computer, so you don't notice that you actually only gave them a piece of your application. It works the same way for *nix users.
For DLLs that are not standard on a system, you need to provide them along with your final executable. (That's why people create installers and RPMs. They handle the application dependencies -- DLLs needed by the application.) An example is when you compile a C++ application using MinGW on Windows, and ship the .exe to your friends and they say it won't run -- because you didn't ship them one or more of the things in C:\MinGW\bin, like libstdc++-6.dll and libgcc_s_dw2-1.dll.
the compiler knows where this stuff is
Now, on the compiler's end of things... Everything about the C and C++ standard libraries are 'special' -- the compiler knows stuff (or can know stuff) about them that it can't know about any other library. Such as, for example, if you compile code using <cmath>, the compiler knows to link with the C Math library -- you don't have to tell it to do that. (Not true of every older compiler, mind you.)
Somewhere on your system are two important directories -- directories that compiler knows about.
The first is the "include" directory, which contains all the stuff you
The other important directory is the "lib" directory, which contains all the information necessary to link to the library DLLs or the code to statically link the library. This is actually a little more complicated that it sounds, but for our purposes that will do. So when you download Foo's special library you must put the Foo static/dynamic library data in the "lib" directory. (That, or tell the compiler stuff... again.)
That, in addition to also giving your friends a copy of Foo's DLLs (like foo.dll) along with your .exe. Remember, the compiler has to be able to find it when compiling. And your program must be able to find the DLL when running.
Phew. Hope that made some sense.
All compiled code must be somewhere.
precompiled code
All compilers in existence come with precompiled standard libraries, almost always in a number of DLLs (.dll on Windows or .so on nixen). That's more than one, mind you. (There's the C standard library, which comes in at least two parts -- the basic part and the math part. And then there's the C++ standard library, which also comes in parts.)
Anything you use from the STL introduces code your application compiles (all the templates are new things created by your application). That said, sometimes some parts can come precompiled. Say, a std::string class -- common enough that your compiler may already have it precompiled and just link it into your final executable, either statically or dynamically. On top of that, some STL code relies on stuff that is already in a precompiled library, like <chrono> does.
precompiled code is usually in DLLs that your user must have
All these things must be connected (or linked) to your final executable. Some of it can be statically linked (compiled as part of your final executable file) but much of it is in DLLs that must be present on your system.
You don't normally notice because (1) your system has those DLLs since you installed the compiler (2) your compiler uses standard system DLLs. For example, everyone who has Windows has Microsoft's standard C runtime library installed. It's part of the system. So compilers that compile for Windows will usually (not all do, but smart ones do) compile against the standard Microsoft runtime library DLLs. You give your friends an .exe file, but that .exe uses DLLs that your friends (should) already have installed on their computer, so you don't notice that you actually only gave them a piece of your application. It works the same way for *nix users.
For DLLs that are not standard on a system, you need to provide them along with your final executable. (That's why people create installers and RPMs. They handle the application dependencies -- DLLs needed by the application.) An example is when you compile a C++ application using MinGW on Windows, and ship the .exe to your friends and they say it won't run -- because you didn't ship them one or more of the things in C:\MinGW\bin, like libstdc++-6.dll and libgcc_s_dw2-1.dll.
the compiler knows where this stuff is
Now, on the compiler's end of things... Everything about the C and C++ standard libraries are 'special' -- the compiler knows stuff (or can know stuff) about them that it can't know about any other library. Such as, for example, if you compile code using <cmath>, the compiler knows to link with the C Math library -- you don't have to tell it to do that. (Not true of every older compiler, mind you.)
Somewhere on your system are two important directories -- directories that compiler knows about.
The first is the "include" directory, which contains all the stuff you
#include <likethis> . (Except maybe some C++ libraries -- some compilers put C++ stuff in weird places. Don't disdain, though, they have raisins.) So if you want to download and use Foo's special library, you must put Foo's headers in the "include" directory. (That, or tell the compiler to add some other directory to the list of directories treated just like the "include" directory. [caveats!])The other important directory is the "lib" directory, which contains all the information necessary to link to the library DLLs or the code to statically link the library. This is actually a little more complicated that it sounds, but for our purposes that will do. So when you download Foo's special library you must put the Foo static/dynamic library data in the "lib" directory. (That, or tell the compiler stuff... again.)
That, in addition to also giving your friends a copy of Foo's DLLs (like foo.dll) along with your .exe. Remember, the compiler has to be able to find it when compiling. And your program must be able to find the DLL when running.
Phew. Hope that made some sense.
Topic archived. No new replies allowed.