I think library is just the implementation of header file I just got the gist of it by seeing library vs header file but here it is shown that container is library with many headers like vector,list etc.
So if i make two files one add.h with declarations of functions and add.cpp with definition of function add.cpp would be library.But is it possible to have more than one header's definition in a single library?
So basically my question is just what is stated in title and I would also like to make sure that I haven't misunderstood libraries and is that all there is to library?
A library is the compiled code (headers (*.h) + sources (*.cpp)). Such library can be linked to your executable. To use the defined functions/classes and such of these library, your compiler needs the declaration of them, which are provided by the headers. The headers are normally provided with the library (*.DLL on windows, *.so on UNIX for dynamic loaded libraries, *.lib on windows, *.a on UNIX for static libraries).
While compiling you have to specify where to find the included headers and also which libraries to link against.
But to summarize your question a library (normally) comes with multiple headers (could also be one) which declare the usable functions/classes of the library. With the headers your compiler knows the signatures of said functions, so he can compile the function calls.
In the link step, the linker links the said functions against the function calls in the "runnable" library.
is it possible to have more than one header's definition in a single library?
Yes. If a library contains more than one function, then you can declare those functions in separate headers. This is in fact very common.
Related
EDIT: I know about include guards, but include files are not the issue here. I'm talking about actual compiled and already linked code that gets baked into the static library.
I'm creating a general-purpose utility library for myself in C++.
One of the functions I'm creating, printFile, requires string, cout and other such members of the standard library.
I'm worried that when the library is compiled, and then linked to another project that also uses string and cout, the code for string and cout will be duplicated: it will both be prelinked in the library binary the program is being linked with, and it will be again linked with the project that uses them itself.
The library is structured like this:
There is one libname.hpp file the programmer who uses the library is supposed to #include in his projects.
For every function fname declared in libname.hpp, there is an file fname.cpp implementing it.
All fname.cpp files also #include "libname.hpp".
The library itself compiles into libname.a which is copied to /usr/lib/.
Will this even happen?
If yes, is it a problem at all?
If yes, then how can I avoid this?
I'm worried that when the library is compiled, and then linked to another project that also uses string and cout, the code for string and cout will be duplicated
Don't worry: no modern compilation system will do that. The code for template functions is emitted into object files, but the linker discards duplicate entries.
The library definitions of the standard C++ library won't show up in your own statically library unless you explicitly include them there (i.e., you extract object files from the standard C++ library and include them into your library). Static libraries are not linked at all and will just have undefined references to other libraries. A static library is merely a collection of object files defining the symbols provided by the library. The definitions which come from the headers, e.g., inline functions and template instantiations, will be defined in such a way that multiple definitions in multiple translation units won't conflict. Where the code isn't actually inlined, it will define "weak" symbols which result in duplicates being ignored or removed at link time.
The only real concern is that the libraries linked into an executable need to use compatible library definitions. With substantial amount of code residing in header files, there are relatively frequent changes to the C++ header files, including standard C++ library headers (relative to the C library headers which contain a lot less code).
Yes, the code for standard library things will be duplicated. It can be a problem if for example you return a std::string or take one as a parameter in one of your methods. It may have a different layout in your standard library implementation than in the user's.
This is rarely a problem in practice.
For static functions and inline templated functions defined in header files, there's nothing to worry about: every compilation unit gets its own copy (e.g. within the .a library there may already be many anonymous copies). This is okay because these definitions aren't exported, so the linker doesn't need to worry about them.
For functions that are declared with non-static linkage, whether you have an issue depends on how you link the .a library.
When you build the library, you typically will not link in the standard C++ library. The created library will contain undefined references to the standard C++ library. These must be resolved before building the final executable binary. This is normally done automatically when linking that final binary in the default way (depending on the compiler).
There are times when people do link in the standard C++ library into a static library. If you're linking against multiple static libraries that each embed another library (like the standard C++ library), then expect trouble if there are any differences in those embedded libraries. Fortunately, this is a rare problem, at least with the gcc toolchain. It's a more frequent problem with Microsoft's tools.
In some cases, a workaround is to make one or more conflicting static libraries into a dynamic library. This way each of these dynamic libraries can statically link its own copy of the problematic library. As long as the dynamic library doesn't export the symbols from the problematic library and there are no memory layout incompatibilities, there generally isn't any trouble.
Pretty much title sums it up.
I'm not sure the difference between the two if i'd like to use a library.
Thanks!
In general, you need both.
Include files contain declarations of types, prototypes of functions, inline functions, #defines, ..., in general every information about the library the compiler needs to be aware of when compiling your files.
Static libraries, instead, contain the actual object code of the functions of the library. If the headers contain the prototypes, the static libraries contain the (compiled) definitions of the functions, i.e. the object modules that the linker will link with yours.
If you only included the header file without linking against the static library, the linker would complain about missing definitions, because you would be using functions declared in the header, but not defined anywhere (i.e. with no implementation). On the other hand, if you only linked the static library without providing the header, the compiler would complain about unknown identifiers, since it wouldn't have a clue about the library symbols you're using.
The concept is very similar to when you compile a multi-file project: to access the definitions written in other .cpp you need to include just a header with their declarations, and the linker in the end links together the various object modules.
As far as dlls are concerned, usually an import library is provided; import libraries are like static libraries, but, instead of containing all the code of the library, they contain small stubs that call the functions into the dll. Every time a call to a library function is encountered in one of your object modules, the linker directs it to the stub, which in turn redirects it to the code into the dll1. All in all, when dealing with dlls on Windows you usually have a .h (prototypes/...), a .lib (import library you link against, contains the stubs) and a .dll (dynamic-linking library containing the actual code of the library).
By the way, some libraries are "header only" (you can find many in boost), which means that all their code is put into a header, so no static library is needed. Such libraries are often just made of inline code (functions/classes/...) and templates, for which no separate definition is needed.
Often this is done because static libraries are ugly beasts for several reasons:
you have to explicitly link against them;
since they are linked directly to your code, they have to use exactly your same C/C++ runtime library, which means that, at least on Windows, it's impractical to distribute static libraries (different compilers, different compiler versions, different configurations of the same compiler use different standard libraries, distributing a static library for every combination of these aspects would be impractical at least);
because of this, in general you have to first compile on your own version of the static library, and only then link against it.
Compare all this with just including a header file... :)
Actually, modern toolchains can recognize these stubs and avoid the extra indirection step. See this series by Raymond Chen for details.
The compiler needs to know the include directories, since it needs to include header (interface) files of libraries you want to use.
The linker needs to know the library directories, since it needs to link your executable to the (precompiled) implementation of the library.
See also What are the differences between a compiler and a linker?
Include directories are just for header files, which typically provide function/method signatures only. You need to link to a library to have access to its actual object code.
See this question.
I'm building a socket program in Visual Studio 2003 .NET
I #include <winsock2.h> header file but also noticed that I had to link in the WS2_32.lib to fix the unresolved winsock function errors.
In other homework projects, I just added a header file and used it's functions - without adding the corresponding library.
How is this so?
Are some standard header file libraries already pre-linked in Visual Studio or something else?
Thank You!
The socket functions are actually implemented in ws2_32.dll. In order for the linker to be able to find them, you need to add the ws2_32.lib import library to your project. Note that the import library does not contain the actual code for the functions, but only information about where to find the actual functions (in ws2_32.dll).
You don't mention which other header files you're referring to, but if it's something like <string.h> then that is already in the MSVC runtime library; if it's something like <windows.h> then those functions are provided by import libraries such as kernel32.lib, user32.lib, and gdi32.lib. Those libraries are probably already included in your linker settings.
By default, Visual Studio includes the most commonly used Win32 .lib files, e.g. kernel32.lib, user32.lib, advapi32.lib etc. For more esoteric libraries, you need to add the .lib files yourself.
By default Visual Studio will link against the standard library, so if you are including a header that is part of that then you don't need to explicitly add the library. This is true for things like stdio.h, iostream and stdlib.h.
There are also some header files such as those used by the Standard Template Library (someone will be along in a minute to say that it's actually just called the 'Standard Library', but most books I've ever read, and Microsoft's docs too refer to the STL) such as <vector> and <list> which define all their code as templates that get expanded into the full functions by the compiler so that they don't need to link in a library.
A slight aside: there's also a mechanism for automatically linking against a library. Just add:
#pragma comment(lib, "ws2_32.lib")
somewhere in your code. Boost uses this technique so that it links against the correct build of the library depending on your compiler settinsg.
This has nothing to do with Visual Studio; this is how compilation of C/C++ works.
All a header does is declare or define symbols. Functions, variables, typedefs, classes, etc.
A header can say:
int SomeFunction();
This is a function declaration. In order for you to compile code that uses SomeFunction, you must declare that SomeFunction exists. And this declaration must be made before your code that uses it.
These declarations are typically in header files.
However, a declaration is also a promise. A function definition is the actual C/C++ source code that makes the function work. A declaration says, "at some later point, you will be able to find the definition of this." This is a promise you are making to the compiler and linker.
You cannot successfully link C/C++ code unless all declarations in use have a definition. Some of these definitions come from your own compiled code, but some of them come from external libraries. External libraries have header files that provide the declaration of C/C++ functions, types, etc. But they also have library files (in VC++, these use the .lib extension) that provide the definition of those functions.
If you use declarations from a header, without linking to the library files that provide the definition of those symbols, you get a linker error.
Note that header files can contain definitions as well; much of the C++ standard library, and must of Boost is defined solely by header files. So there are no libraries to include. The library's documentation should tell you whether there is a .lib to link against or not.
Hey so i'm a little confused on why, in msVS++ 2010 you have to have include directories when all the headers and cpp files are inside the static libray or static library project in my case.
I made the static library project with cmake, and the source file i was told to set it to is the same i'm now told to make the include directory... it seems like I have 2 of the same cpp and header files.. except ones included statically in my sollution... WHY?
Because VS++ while abstracting the underlying implementation does not hide it completely.
Include directories and libraries are targeted at different phase of the process, which are traditionally handled by different programs. Include directories by the preprocessor, libraries by the linker. Those programs are now called (or part of?) VC++, but its interface still shows the underlying structure.
There are systems which allows to mark the needed libraries in the source code (and thus in the header) by the use of pragmas. Those have several disadvantages:
non standard
you can't as easily substitute libraries by another (say debug/instrumented/release, single thread/multi thread, ...)
Header files tell you about the functions you're calling.
Static libraries include the code of the function you're calling, but not information about how to call them.
Why do we need to add both includes and libs to the compilation?
Why doesn't the libs wrap everything in it?
Header files define interfaces; libraries provide implementations.
The header for a library is going to tell your compiler the names and signatures of functions provided by the library, the names of variables provided by the library, and the layout of classes provided by the library.
The library itself is compiled code which is executed at run time. Using the header during compilation allows your compiler to generate compiled code which knows how to invoke and communicate with the existing library code.
A header file (usually) only contains declarations for classes and functions. The actual implementations are built from CPP files. You can then link against those implementations with only the header declarations available.
I'm guessing this is your way of handling the question you asked at How to make #include <mysql.h> work?
Unfortunately, I think the better solution is to either learn more about C++, or learn more about Google, before posting absolutely everything to this site.