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.
Related
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.
Let's say I have 10 *.hpp and *.cpp files that I need to compile a code. I know that I will need those same files for many different codes. Can I create a "package" with those files that would allow me to simply write:
#include <mypackage>
instead of:
#include "file1.hpp"
#include "file2.hpp"
...
#include "file10.hpp"
I wouldn't then need to write a makefile every time I need this "package".
To be more precise, I use Linux.
A collection of CPP sources (H files and CPP files) can be compiled together in to a "library," which can then be used in other programs and libraries. The specifics of how to do this are platform- and toolchain-specific, so I leave it to you to discover the details. However, I'll provide a couple links that you can have a read of:
Creating a shared and static library with the gnu compiler [gcc]
Walkthrough: Creating and Using a Dynamic Link Library (C++)
Libraries can be seperated in to two types: source code libraries, and binary libraries. There can also be hybrids of these two types -- a library can be both a source and binary library. Source code libraries are simply that: a collection of code distributed as just source code; typically header files. Most of the Boost libraries are of this type. Binary libraries are compiled in to a package that is runtime-loadable by a client program.
Even in the case of binary libraries (and obviously in the case of source libraries), a header file (or multiple header files) must be provided to the user of the library. This tells the compiler of the client program what functions etc to look for in the library. What is often done by library writers is a single, master header file is composed with declarations of everything that is exported by the library, and the client will #include that header. Later, in the case of binary libraries, the client program will "link" to the library, and this resolves all the names mentioned in the header to executable addresses.
When composing the client-side header file, keep complexity in mind. There may be many cases where some of your clients only want to use some few parts of your library. If you compose one master header file that includes everything from your library, your clients compilation times will be needlessly increased.
A common way of dealing with this problem is to provide individual header files for correlated parts of your library. If you think of all of Boost a single library, then Boost is an example of this. Boost is an enormous library, but if all you want is the regex functionality, you can only #include the regex-related header(s) to get that functionality. You don't have to include all of Boost if all you want is the regex stuff.
Under both Windows and Linux, binary libraries can be further subdivided in to two types: dynamic and static. In the case of static libraries, the code of the library is actually "imported" (for lack of a better term) in to the executable of the client program. A static library is distributed by you, but this is only needed by the client during the compilation step. This is handy when you do not want to force your client to have to distribute additional files with their program. It also helps to avoid Dependancy Hell. A Dynamic library, on the other hand, is not "imported" in to the client program directly, buy dynamically loaded by the client program when it executes. This both reduces the size of the client program and potentially the disc footprint in cases where multiple programs use the same dynamic library, but the library binary must be distributed & installed with the client program.
On Linux:
g++ FLAGS -shared -Wl,-soname,libLIBNAME.so.1 -o libLIBNAME.VERSION OBJECT_FILES
where
FLAGS: typical flags (e.g., -g, -Wall, -Wextra, etc.)
LIBNAME: name of your library
OBJECT_FILES: objects files resulting from compiling cpp files
VERSION: version of your library
Assuming your "file1.hpp" and "file2.hpp" etc are closely related and (nearly) always used together, then making one "mypacakge.h" that contains the includes of the other components is a good idea (it doesn't in and of itself make it into a library - that is a different process altogether).
If they are NOT closely related and/or used together, then you shouldn't have such a "mega include", because it just drags in a bunch of things that aren't needed.
To make a library involves building your code once, and either generating a .lib file or a shared librar (.dll or .so file). The exact steps to do this depends on what system you are using, and it's a little too complicated for me to explain here.
Edit: To explain further: All of the C++ library is actually one library file or shared library file [along with a number of header files that contain some of the code and the declarations needed to use the code in the library]. But you include <iostream> and <vector> separately - it would become pretty awful to include EVERYTHING from all the different C++ library headers in one <allcpplibrary>, even if it was a lot less typing involved. It is split into sections that do one thing per headerfile. So you get a "complete" set from one header file, but not a too much other things you don't actually need.
Yes and no.
You can write an include-all header so that #include "myLib.h" is sufficient, because you include all those headers through the single header. However, that does not mean that the single include is enough to have the content of the 10 '.cpp' files linked to your project automagically. You will have to compile them into a library and link that single library (instead of all the object files) to the projects that use "myLib.h". Library binaries come as static and dynamic libraries, the files are typically named .lib and .dll (windows) and .a and .so (linux) for static and dynamic libraries, respectively.
How to build and link such libraries depends on your build system, you might want to loke those terms up on the net.
One alternative is to get rid of the .cpp files by defininig all the functions in the headers. That way you won't have to link the additional library, but it comes at the cost of increased build times, because the compiler will have to process all those functions every time you include the header directly or indirectly into one of your translation units.
If a client needs all ten headers to actually make use of your "package" (library), that's pretty bad interface design.
If a client needs only some headers, depending on which parts of your library are being used, let the client include the appropriate headers, so only a minimal set of identifiers are introduced. This helps scope, modularization, and compilation times.
If all else fails, you can make an "interface header" for external use, which is different from the ones you use internally for actually compiling your library. This would be the one that gets installed, and consists of the necessary contents from the other headers. (I still don't think you would need everything from every header in your lib.)
I would discourage Salgar's solution. You either have individual headers, or a monolithic one. Providing individual headers plus a central one that simply includes the others strikes me as pretty poor layout.
What I do not understand is inhowfar Makefiles play into this. Header dependencies should be resolved automatically by your Makefile / build system, i.e. it shouldn't matter here how your header files are layed out.
simply all you'd have to do is create a .h or .hpp file that has
#ifndef MAIN_LIB_H
#define MAIN_LIB_H
#include "file1.hpp"
#include "file2.hpp"
#include "file3.hpp"
...
#include "file10.hpp"
#endif
make the file called whatever I would choose main_lib.h because of the ifndef, and just
#include "DIRECTORY PATH IF THERE IS ONE/main_lib.h"
in the main file. No need for anything else if you were using visual studios. Just build then press CTRL + F5.
We can include < iostream > and we do not care about its cpp file, but why can't we do the same for our own classes ?
So if my project uses 50 custom classes, not only do I have to have 50 includes, but also have to compile/link 50 cpp files along with them (and clutter the project tree).
Q: Is there any way to use custom headers the same way we use standard libraries ?
In other words is there a kosher way so that we do not have to add all those cpp files in the project. I want to only include ClassSnake.hpp which in turn knows where to find ClassSnake.cpp which links to ClassVector.hpp which knows how to find ClassVector.cpp ... all in an automatic daisy chain without me having to explicitly add those cpp files in my project tree.
Edit: I am not worried so much about the cpp files recompiling. My issue is with having to remember which class internally links to which other class, so that I can properly include all those hidden cpp files in the project tree ... and clutter the tree.
Not really.
What you're missing is that your compiler toolchain has already compiled the bits <iostream> needs that aren't in the header.
Your compiler (linker really) just implicitly links this code in without you having to specify it.
If you want to clean up your project tree a bit, you could create other projects that are libraries of code for one main project to use.
Headers do not (normally) provide implementations of things (functions, classes), they must be implemented somewhere if you are going to use them.
When you include your own header, you include your own sources in order to provide the implementation. Straight forward enough there.
When you include a standard header (such as iostream), the implementation is in the libraries you include (either implicitly because the compiler just does it, or explicitly through compiler/linker options).
As an extention to Collin's answer, you could always offload "shared" code to a shared library, and then reference the header files and lib files in your other projects. The lib files will only come in to play at the linker stage, as all those other pesky .cpp files have already been compiled.
If this is is just a self-enclosed project with no other commonality, you're just going to have to suck up the fact you have to provide an implementation :)
First of all if you use a system such as make then it will identify that the .cpp file has not changed and therefore the compiler does not have to reconstruct the object file.
You can also create your own static/shared library. The method to do this depends on the platform. If you go down this avenue then all you need is the header file along with the library.
Please Google on how to construct how to make a library for you particular platform.
Actually, if you have a decent build process cpp files that have not changed will not be compiled again. They only have to be linked. If you don't want that either you need to create your own libraries. It can be done, is just a bit more involved.
Edit: This question might help you if you want to create your own library.
So answer to edited question: Yes, you can avoid having all those cpp files in the project but only if you don't want to change them. In this case you can just create a static or dynamic library and you will only need the symbols for linking. In that case you would create another project to compile everything into such a library.
STL code like "iostream" is made of templates no code is actually generated until instances of the templates are created.
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 have a bunch of projects that all could share a "common" static library of classes.
What confuses me is if I make a static library out of these classes and link against it in my projects that I still need the headers of the classes in the static library in my main projects.
What is the benefit of the static library then?
How do companies like Adobe deal with this?
Static libraries allow you to create a library and use that library in many projects.
The need for header files:
Since the project using the library is programmed and compiled independent of the library, that program needs to know the declaration of the things you're using. Otherwise how would your compiler know you're writing valid code?
A compiler only takes source code as input and produces output. It does not deal with compiled object files or static libraries on input.
The need for linking in the library:
So having the headers allows you to write valid code in your project, but when it comes to link time you'll need to provide the definition which is contained inside the static library.
The linker takes all object files (compiled code) and also all static libraries and produces an executable or binary.
More info about static libraries (benefits, comparing dynamic, etc...):
Amongst other things, it is nice to separate your project into libraries so that you don't end up with 1 huge monolithic project.
You do not need to distribute the source code (typically in the .cpp files) this way.
If you were to simply include all the .cpp files in every project that used the common library then you would have to compile the .cpp files each time.
An advantage of static libraries over dynamic libraries is that you can always be sure that your programs will be self contained and that they are using the correct version of the library (since they are compiled into the executable itself). You will also have a slight speed advantage over dynamic linking.
Disadvantages of static libraries over dynamic libraries include that your file sizes will be bigger because each executable needs their own copy, and that you can't swap out a different version of the library since it's not dynamically loaded.
Re your question: How do companies deal with this:
A typical company will make use of both static and dynamic libraries extensively.
The typical way you make use of a static library is to have a target in your Makefile (or whatever build system you use) that installs the headers into an appropriate location at the same time that it installs the library.
So, your static library ends up in /usr/local/lib, and the headers go into /usr/local/include or wherever.
Also, when compared with linking against object files, linking against static library may result is a smaller final executable. The reason for this is, if you don't call any of the functions from a particular object file (included in the static library), the linker will not include the code for those functions in you final executable. See Extraneous Library Linkage