In my c++ project, I have some preprocessor macro commands.As an example:
#define ENABLE_PHOTO_SENSOR //will be put in three source file (.cc file)
#define SAVE_ROOT_FILE //will be placed 6 source file
...
Should I have to put all these macro commands in a single header file? If I do like this, when I change one of the macro commands(example undef one macro) and compile the program again, all the source files including those header files are compiled again. If I use separate header file for each macro command, only related source file compiled. But what I want is to control all the macro commands from a single file and when I change a macro command, only the files related to that macro commands are changed.
Finally, I am using cmake to generate make files. Is it possible to change these macro commands in the build directory?If it is how?
I've read a bunch questions on this site about the usage of add_executable function in CMake, but have not found an exact answer to my confusion.
My question is why we only add .cpp files in the add_executable function but not .hpp files?
I understand header files are like "indices" for functions and classes in the corresponding .cpp files. But if we don't include them in the add_executable function, how are they used in the build process?
For example, will the A.hpp file be used when another source file import A.hpp? But then A.hpp is not in the add_executable function... How does the program know where to find A.hpp?
Thanks!
Header files, which often have .h or .hpp extension, although not always - for example, C++ standard library headers have no extensions - are "copy-pasted" by compiler into every .cpp (or .C, or .cc) which has #include directive to include the file.
Because of that, build system, such as CMake, doesn't have to know about them when the final executable is built - their contents is already accounted for by literal inclusion of their code into .cpp file.
However, build systems need to know about those files when dependencies are specified - to ensure that the whole application is rebuilt whenever any of those files is updated, and also to provide the proper inclusion path to the compilation command.
I have written certain macros in a headerfile(.h)file. I want those macros to be used in a makefile in linux OS. How can i declare (or) get that macro definitions from a header file in to a makefile.
I have added the file using "-include" in a makefile, but i could not read the macro definitions.
You can't. Header files are for C code.
I created a class (say, myclass.h/cpp). I want to use the class from many different places. Therefore, I put those files in a folder (say, C:\cpp_include) and I want to include them from whatever folder my codes are. I have a code which uses the class (say, main.cpp). In main.cpp, I include myclass:
#include "myclass.h"
I compile using a .pro file and nmake. In the .pro file, I specify the folder as:
INCLUDEPATH += C:\cpp_include
When I compile the code using nmake, myclass.h is properly included, but myclass.cpp doesn't seem to be found by compiler.
When I specify myclass.cpp as one of the source files in .pro file:
SOURCES += main.cpp C:\cpp_include\myclass.cpp
The exe file is built correctly. But, I would like myclass.cpp file to be found automatically when myclass.h is included, i.e. without setting myclass.cpp as a source file. Would this be possible? It looks like that's what happens with classes from Qt and Qwt (e.g .h/cpp files in /src/ folder in Qt and Qwt). Am I missing somthing?
Thanks a lot!
Daisuke
A simple technique is to have build scripts (makefiles) in the cpp directories. Write a rule that traverses the directories, executing the build scripts. This one step in isolating functionality and also allows one to use libraries.
That's just not how it works. The .cpp is the file that matters, header files (.h) just get copied into the other .cpp files. Therefore you need to add the myclass.cpp to your sources for compiling. Or, if it's a library class, you could also compile it once into a static library (.lib) and just add that to your linker files. But you ultimately need to somehow include you implementation in the project where it's used.
In Python whenever I had a bunch of functions that I wanted to use across multiple programs I'd make another .py file and then just import that wherever I needed it. How would I do that in C/C++? Do I dump both prototype and implementation into an .h file? or do I need to place the function prototypes in the .h file and the implementations in a separate .cpp file with the same name as the .h file and #include the .h wherever I need it?
You need to do a couple of things:
Add the prototype to a header file.
Write a new source file with the function definitions.
In a source file that just wants to use the shared function, you need to add #include "header.h" (replacing header.h with the name of the file from step 1) someplace before you try to call the shared function (normally you put all includes at the top of the source file).
Make sure your build compiles the new source file and includes that in the link.
A couple of other comments. It's normal to have foo.h as the header for the foo.c but that is only a style guideline.
When using headers, you want to add include guards to protect against the multiple include issue.
In C/C++ we usually put declarations in .h files and implementation in .c/cpp files.
(Note: there're many other ways, for example the include, templates, inline, extern, ... so you may find some code only in header files or only in c/cpp files - for example some of the STL and templates.)
Then you need to "link" the file with your program, which works like the "import" in Python interpreter but actually works in static linking object files together into a single executable file.
However the "link" command and syntax depends on your compiler and OS linker. So you need to check your compiler for more information, for example "ld" on UNIX and "link.exe" on DOS/Windows. Moreover, usually the C compiler will invoke the linker automatically.
For example, say you have 2 files: a.c and b.c (with a.h and b.h), on gcc:
gcc -o a.out a.c b.c
On MSVC:
cl a.c b.c
There are two ways to approach this that differ only slightly. As others have said, the first steps are:
-Create a header file which contains your function prototypes. You'll want to mark this with
# ifndef myheader_h
# define myheader_h
// prototypes go here...
# endif
to prevent problems with multiple inclusions.
-Create a .c file which contains the actual definitions.
Here's where the solutions branch.
If you want to include the source directly in your project, make the .c file part of your compilation stage as well as your link stage.
However, if you really plan on using this across multiple projects, you'll probably want to compile this source file independently, and reference the object file from your other projects. This is loosely what a "library" is, though libraries may consist of multiple object modules - each of which has been compiled but not yet linked.
update
Someone pointed out that this really only keeps the header from being included in a single cpp file. News flash: that's all you need to do.
Compilers treat each cpp file individually. The header files included by each cpp source file tell the compiler, "hey! This thing is defined in another source file! Assume references that match this prototype are A-OK and keep moving on."
The LINKER, on other other hand, is responsible for fixing up these references, and IT will throw a fit if the same symbol is defined in multiple object files. For that to happen, a function would have to be defined in two separate source files - a real definition with a body, not just an extern prototype - OR the object file that contains its body/definition would have to be included in the link command more than once.
Re:"inline"
Use of "inline" is meant as an optmization feature. Functions declared as inline have their bodies expanded inline at each place where they are called. Using this to get around multiple definition errors is very, very bad. This is similar to macro expansion.
See Francis's answer. The sentence that you wrote, "or do I need to place the function prototypes in the .h file and the implementations in a separate .cpp file with the same name as the .h file and #include the .h wherever I need it?", is pretty-much correct. You don't have to do things exactly this way, but it works.
It's up to you how you do this, The compiler doesn't care. But if you put your functions in a .h file, you should declare them __inline otherwise if you include the header file in more than one .cpp file, you will have multiply defined symbols.
On the other hand, if you make them __inline, you will tend to get a copy created in each place that you use the function. This will bloat the size of your program. So unless the functions are quite small, it's probably best to put the functions in a .cpp and create a parallel .h with function prototypes and public structures. This is the way most programmers work.
On the other hand, in the STL (Standard Template Library), virtually all of the code is in header files. (without the .h extension)