I'm new to C++. I just downloaded the Boost libraries to study. I wanted to look into some implementation details, so I looked for .cpp files. To my surprise, I haven't found any so far.
There seem only .hpp files out there. Where are the .cpp files?
From the Boost documentation:
Most Boost libraries are header-only: they consist entirely of header
files containing templates and inline functions, and require no
separately-compiled library binaries or special treatment when
linking.
See that link for the list of libraries that are not header-only and must be built separately. For those libraries, the .cpp files are in the /libs directory of the Boost distribution. If you got the precompiled package, you'll instead find the already-compiled .lib files in the /lib directory.
The .hpp files are the headers that you must include in your code in order to use Boost classes. Many Boost libraries are header-only; all of the implementations are in the .hpp files. For those that do have source, you only see the compiled versions as .lib files.
If you download a source distribution of Boost, it should have several subdirectories:
boost: contains .hpp headers
lib: contains .lib files (compiled implementation details)
libs: the source of those implementation details
Because many (but not all) of the libraries are implemented using templates, and must therefore be placed within header files.
A lot of the Boost library are purely template. In the previous standard of C++ there was already the keyword export to allow the developer to separate the implementation from the interface.
The sad truth was that the keyword never worked completely (difficult to implement from the compiler vendor point of view and difficult to use it right for the developer). One way to fix the problem was provide interface and implementation in a header file and avoid the implementation file. By the way, there are several Boost libraries that you need to compile and link in order to use it, and I bet you will find implementation files in those libraries.
For those which aren't header-only, the source files can be found inside the libs sub directory.
I believe the majority of the Boost libraries are implemented in the actual header files only, as previous posters mentioned. As was also mentioned, compiled implementation code will be included as separate library files when separate from the header files.
You mentioned being new to C++, so I think it's worth mentioning that this type of library distribution is not particular to Boost. Other third party libraries and APIs you use will likely be structured in the same way; you will find packages of header files and library files only, with no .c, .cxx, .cpp, etc files. This is done for a number of reasons, including to hide the implementation of the library functionality, and to allow shared libraries to be loaded into memory once each.
This article might help clarify things for you:
http://www.learncpp.com/cpp-tutorial/a1-static-and-dynamic-libraries/
You are probably looking at precompiled package, where cpp files are available in shape of libraries, not source. If you actually grab the source you will find some cpp files.
Related
I couldn't really find anything on Google or SO about this. I don't know if it's because it's uncommon, or because I am using the wrong terms to search. I read this question here, but it didn't really answer my question.
So what I am doing is trying to build a library on top of SDL for C++. Now what I can't seem to figure out is how to make projects that use my library be totally independent from SDLs files except the dll.
When I make my library, I link with SDL2.lib, and SDL2main.lib. I include all of SDLs header files into my libraries files. When I build, it generates my library file; GGL.lib.
But when I want to test my library in another project, I have to include all of SDLs header files, because in my project's Window.h, it includes SDL.h. I am wondering if there is any way for me to make my libraries header files independent from SDL except for the dll.
You obviously need to avoid including SDL header files in header files of your library. Include them only in source files, where possible. This removes redundant dependencies and speeds up compilation process. But you want complete independence, so if you can't remove one #include directive, you failed.
If you need to declare a pointer of an SDL type in your header (like one usually does with SDL), forward declare it. That type will however remain incomplete to the users of your library. In case your library is object-oriented, there's Pimpl Idiom, which is based on the same principle - this hides everything.
In c/c++ we use -I for specifying header files location and -L path for specifying library path. I have an eigen and boost libraries, so what I did is that I copied these libraries to /usr/include directory in linux and in source file of my program I just used the header file of these libraries. My question is how does the source file of these libraries get linked with my program source file in which I am only using header files of these libraries?
It depends on the libraries you are using. Eigen3 is header-only: no need to link against it. With Boost, it depends. Most parts are header-only but some libraries might need to be linked.
On the copying to /usr/include. This sounds horribly wrong. Use the package manager of your distribution to get a package of the libraries you require. You should almost never put files yourself into /usr/{include|lib...} directly but prefer /usr/local/{include|lib...}.
You are also a little confused about source code and object code. Generally, a library will contain compiled, object, code, but C++ template expansion requires some kind of source code or source-like code in order to perform template instantiation.
However, the bottom line is that the syntax to include a library depends on the compiler/linker combination you are using. You need to state that before someone can answer the question fully.
The directory "/usr/include" is considered special, part of the operating system or platform you are using, so you should not copy files into it.
Note that the construction "c/c++" is not very meaningful - the two languages C and C++ have different syntax and different linkage models. Best to say which one you meant.
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.
I'm trying to separate some of my code and put it in a shared library that I will be able to use from other places. In the documentation:
http://doc.qt.io/archives/qt-4.7/sharedlibrary.html
They say that you cannot link to other header files. How would I be able to include shared headers into my shared library?
Shared libraries in the context being discussed in the link you provided are .so (shared object) files (.dll, dynamic link library, on Windows), or static (.lib) libraries. Qt provides this kind of library; so do many other vendors/projects. To use them in another application (like yours, for example), you include the headers and link against the library.
What the article is warning about is #includeing header files that a user may not have - i.e. ones that aren't part of your project. Remember, for someone else to use your new "shared library", they need to include the header file(s) that you provide. If that file includes other headers that they don't have, they will get errors.
To avoid this problem, do your #includes in your implementation (.cpp) files; that way, they are hidden from future users. Qt recommends the "pointer-to-implementation" (pimpl) idiom - all the implementation details are hidden from the users of the class, including any and all header files that the implementation depends on.
You can easily do the same thing, even if you don't go all-out with pimpl. The goal is to #include in your header only the absolutely required files, hopefully all of which you provide with your library.
I was looking at the source code for ncmpcpp, and I saw this.
#include <mpd/client.h>
Inside that file are functions which are used by ncmpcpp. But those are just the headers. Don't the cpp files have to exist somewhere as well? I couldn't find them in the same directory. Where are they?
Also, when something that's included is surrounded by < and >, how do I know where to look?
If it's a third-party library, most likely the source code won't be included. Nor is it needed. All symbols declared in the headers (which are meant to be used) should be exported in the .lib file which was probably shipped with the headers.
Unless you have templates, which could be inline.
You only need the cpp files, or, more generally, the implementation files, if you want to compile the code yourself. Which you don't. You can use the module having just headers and binaries.
Of course, the example of open-source projects comes to mind, where all files are generally included, but if it's a commercial product, why release the source code? What's keeping any competitors from just copying it and resell it under a new name?
There's no standard rule that tells where to look for headers that are delimited by <> or "", but the general consensus is that <> are to be used for system headers (like string or iostream) and "" for own headers (myclass.h). It just tells the compiler where to look first.
The source files aren't needed if there is a library (static or dynamically linked) with it that the compiler can link to, these are generally .a or .lib files (though very rarely you might need a .def file).
For search paths, see this for MSVC and this for GCC.