This may be a naive question since I'm a c++ beginner.
In a typical cpp project, we have cpp files and their header files. So based on my understanding, usually cpp files have definitions, while respective header files have declarations. During compiling, we have to include very cpp files in the project since header files do not specify the location of the definition of the declared object. Finally, linker links declaration and definition. This allows the communication between different translation units.
However, when it comes to std:: library, we do include header files but never compile its cpp files. For example, we write #include in main.cpp, but when compiling, the command does not have anything like g++ vector.cpp main.cpp ...
I even tried to search cpp files in the std library folder in my system, but all I can find is various header files.
I do know the definition and declaration can be included in a single header file, I don't think this is how std:: is wrote. Otherwise, it will result in multiple copies of definition when included in different cpp files.
Please help me to understand how this works? Can I do something like this with my own project?
When it comes to templated libraries, the source code must be found in the header files (.h or .hpp), so it is not exceptional to find header-only libraries.
If part of the code is not templated and its implementation is made in source files (.cpp), usually the code is precompiled and supplied as .lib (.a/.so) files to be linked to.
As regards open source APIs, if there are .cpp files they are delivered as well and you have to compile/precompile them by yourself.
Yes, there is compiled code in the standard library. You don't have to compile it because the library comes already compiled with your compiler. And you don't explicitly link to it, because the compiler knows about it. So you don't see it mentioned anywhere when you do normal builds. If you set your compiler to some form of verbose mode you can see that the name of the standard library gets passed to the linker, which pulls the code it needs from the library.
Related
Is it possible to compile header files with C/C++ preprocessor direktives? (Defines)
I have a project with some header files which are without a cpp file. For example typedefs for different platforms.
I'm looking for a simple solution that can be integrated into my cmakefile.
Are you looking for precompiled headers maybe? They can be compiled by a makefile.
If your headers are included in cpp files, they will automatically be used. If they are not included, what is the point of 'compiling' them ?
So basically, the answer is no, you cannot compile only header files. The purpose of compilation is to produce an executable, a file that do actions when executed. Definitions are not actions, they do nothing on their own.
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 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.
Is there a way to #include "library.a" or it's .so or it's .o inside a cpp or cc file?
I would like to do this because I am using this file inside another file.
#include is for C++ code.
.a, .so and .o files are not C++ code.
It's more likely that you want to #include a C++ header file (typically ending in .h or .hpp), and link an object file.
You can do this in the Visual C++ compiler, using #pragma comment(lib, "libname")- and the similarity is somewhat dubious. However you will have to discover any alternatives for your own favourite compiler.
#include is used for telling the compiler about the functions from a library which you will call in your code, that is to say it includes C++ code. Generally this takes the form of header files which have the function declarations in them.
.a and .so and .o files are compliled code which can be linked into your compiled code using the linker.
Edit: there's an introduction about compiling and linking here
The #include statement basically just includes other source code into the current file. That being said, a static library is not source code and cannot be included in this manner. Static (and shared) libraries are instead linked into the project after all the compiling is done.
What you have to do is to include a file containing prototypes to the functions you are going to be using. This way the compiler knows it is there and the linker will sort out the rest.
For more information on how to create and link static/shared libraries, check out this page.
It simply doesn't make sense.
You include the library's code at compile time by linking it.
Normally there's a header file for the library you can include.
In C/C++ project, mostly the file can be of either types .h or .c/.cpp. Apart from their naming difference such as header and implementation files; is there any functionality difference ?
In other words: if in a working C/C++ project what difference it makes if we change all files with .c or .cpp extension ?
[Note: We can also have #include guards for .c/.cpp files. We can skip their compilation if they are observed as headers.]
Edit:
Debate is not intended for this as I don't have any solid use case. Rather I wanted to know, that allowing to give .h,.hxx,.i extensions are just a facility or a rule. e.g. One functionality difference I see is that .cxx files can have their likable object files.
What difference does it make? The compiler is perfectly happy about it. To it, it's just files.
But to you? You makes a lot of difference:
you're no longer able to immediately figure out which one is the header and which one is the implementation;
you can no longer give header and implementation the same name;
If you are using gcc, and you try and compile a bunch of C++ files labled with a .c extension, it's going to try and compile your file as-if it were a C-language file, which is going to create a ton of errors.
There's also project sanity as well ... this is why many times you'll see projects actually label C++ headers as .hpp rather than just .h so that it's easier to create a distinction between C-language source-code and headers, and C++ source-code and headers.
Header files generally must not be compiled directly but instead #included in a file that is directly compiled. By giving these two groups of files their own extension it makes it a lot easier to determine which to compile.
Make and IDE's and other tools normally expect the conventions of .c/.cpp for source and h/hpp for header. Compiler normally goes a step further and defaults to C compilation for .c and c++ compilation for .cpp
Hence, a bad idea to give your headers the same extension as the the source files.