I've been using code blocks for a long time, but never really made my programs into actual code blocks projects. I tried to do it today, and I kept getting errors due to code blocks not recognizing my files. Here is what I have : ---->
CodeBlocks Include Error
When I try to buiild my project I get that cout,cin and my class objects are not defined in my menu.cpp file. So I can only guess code blocks is not properly handling the files.
I would love if someone could help me out as to why this is happening.
Thanks a ton in advance :)
When I try to buiild my project I get that cout,cin and my class objects are not defined in my menu.cpp file.
That's because they're not. You #included neither iostream nor class.h in menu.cpp, so you can't access the declarations therein.
Note that Code Blocks (just like any properly set up build tools) will compile each cpp file separately. This means that not only will it compile menu.cpp as part of the compilation of main.cpp (because you include it), it will also compile it on its own. In the latter case the includes from main.cpp will not be available, so menu.cpp needs its own includes.
This also means that once it does compile (i.e. once you added the includes), you'll get a linker error because the definitions from menu.cpp are now defined twice (once in main.o -- because you included menu.cpp in main.cpp -- and once in menu.o). That's the reason why you should never include cpp files into each other.
PS: This is unrelated to your problem, but it's considered bad practice to use using namespace in a header file. You should put that in your cpp files instead (if you want to use it at all). You should also put the #include <iostream> in those files where you actually need it, rather than the header file.
Related
I'm an experienced programmer, but only in high level languages; I'm doing my first really large project in C++ right now.
I've got two classes, ClassA and ClassB; a ClassA is (among other things) an index of ClassBs, so ClassA needs to know what a ClassB is to build arrays out of it, and a ClassB needs to know what a ClassA is so it can update the index when something changes. Both of these classes are in their own .h & .cpp files.
I figured including each from the other would just cause infinite recursion, so I decided to instead have #include "ClassA.cpp" and #include "ClassB.cpp" at the beginning of main.cpp; but doing this just caused the compiler to warn about multiple definitions of every class and method in those files.
After some experimentation I found out that including ClassA.h and ClassB.h produces the desired behavior - but this doesn't make any sense, I'm only including the prototypes of those classes. Surely the code that actually makes them up never gets mixed in? And yet it does.
What's going on here that I don't understand? Why does including ClassA.h also make the actual code for ClassA show up with it? And why does including ClassA.cpp cause every include of ClassA.h to trigger "multiple definition" errors even though they're in a header shield or whatever it's called?
The missing step is that the definitions in ClassA.cpp and ClassB.cpp will not be seen by the linker unless those files are also compiled at some point. If you did something like this:
g++ main.cpp ClassA.cpp ClassB.cpp
then all references to definitions in ClassA.cpp and ClassB.cpp from main.cpp would be resolved. However, if you only did
g++ main.cpp
then the linker would have no idea where to find the definitions in ClassA.cpp and ClassB.cpp and you would probably get an error.
If you're using an IDE, this detail is hidden from you: the IDE ensures that as long as you add a .cpp file to your "project", it will be compiled into the final binary when you build the project.
This is the way how C++ is designed:
Your classes don't need to now anything more than the prototypes of other classes, so you don't have to include more than the headers.
Why is this so? Well, compilation of an entire application is the combination of two steps: compilation of the code itself and then linking (actually, there is a third step preceding these: pre-processing, but we could consider this one as part of code compilation).
Example function call: It is sufficient (exception: inline functions!) to know that a function with a specific proto type exists. The compiler then can generate all the code necessary to do the function call, except for the actuall address of the function - for which it leaves some kind of place holder.
The linker then combines all code generated during the compilation step to a single unit. As now knowing where every function is located, it can fill their actual addresses into the place holders, wherever they may appear.
C++ code is compiled to *.obj for per .cpp file, and it is the link process make the obj files to an executable.
Never include *.cpp because it usually causes redifinition issue.
For each *.h file, add a macro to avoid multiple including:
#ifndef XXX_H
#define XXX_H
//your code goes here
#endif
This question is about something that after more than a year with C++ I can't solve or find any solution about it.
I got used to using separate files for headers and code in C, but I have a problem with it on C++: whenever I edit a header file and try to compile the code that uses it again, the compiler doesn't notice the change on the header.
What I do to solve this is "compiling" the header (.hpp) alone. Sometimes I just add it to the list of source files for g++ along with the rest of the code, but what happens then is that I have to execute the command twice (the first time it gives me errors, but not the second time). It also warns me that I'm using the "pragma once" option in a main file.
I know this is very wrong, so I've searched for a correct way to do this, without success. I have noticed that g++ generates ".gch" files but I don't really know what's their purpose, although they may be related.
I suspect that the problem is caused because of the code in the ".hpp". I know (I think) that the good way to do it is to define prototypes only inside the header and writing the body of the methods in a separate file, but sometimes (specially when using templates) this generates even more problems.
The .gch is a precompiled header and it is created if you explicitly compile a header file.
The compiler will then use that file instead of the actual header (the compiler does not care about modification timestamps).
Do rm *.gch and leave all headers out of the compilation command forever.
(And don't put template implementations in .cpp files.)
I always have problems with c++ on this, I spend more time trying to solve dependencies instead of programming when I setup a new project. I search the internet a way to do this automatic, or softwares that do that. In fact, I always program on geany and compile with shell script files...
So, is there a software to manage this? Do IDE's do that?
I always include .cpp files on my main.cpp and then I include the .hpp files on these .cpp. So, if I have a main.cpp, a object.hpp and a object.cpp, I will include the object.cpp in the main.cpp and the object.hpp on the object.cpp. Is there a better way to do that?
Can I just include the .hpp files and in the build script add every .cpp file?
I just cant find the answer on the internet, maybe im doing the wrong question...
I have found a nice article dealing with including files.
Common practice for all c++ header files is to simply define inclusion guards.
#ifndef TEST_H
#define TEST_H
// class definitions goes here
#endif
If there are some cyclic dependencies, consider forward declaration.
Every-time this header is included, the compiler checks, whether symbol TEST_H has been defined already. This basically guarantees, that contents of this file are included only once, and so that there is single declaration of the classes, defined in header file.
Good to know is, that directive "#include <>" does copy and paste all the contents of the included file.
Including .cpp file is not strictly disallowed, and sometimes good choice, it is considered a bad practice. As I mentioned, including file, means that all contents of the file are being duplicated at the place of inclusion. This is okay, for the header file with inclusion guard, but not okay for .cpp file, since every function definition inside this file, will be duplicated.
Not including file in the build script means, that only the those duplicated data are included in the build, otherwise you would end up with multiple function redefinition errors.
If you are looking for IDE, consider:
Visual Studio
Code Blocks
Eclipse
IDE won't do all the work, but you can be significantly more productive using good IDE.
TLDR:
Use inclusion guards
Include all .cpp files in build script.
Do not "#include" .cpp files.
In every .cpp file, include only needed headers, to reduce compilation time.
I see a lot of good suggestions with good practices but your mistake (including .cpp files from a .cpp file) suggest you're missing some concept in the C/C++ build process, I hope a little explanation would help you understand better and avoid the mistake.
Think of .c .cc .cxx .cpp files as modules, a .cpp file is a module, with your implementation of something, .h .hpp are just headers where usually you don't put implementations but declarations to be shared with multiple modules.
Usually each .cpp module is compiled to a binary object g++ -c -o mymod1.o mymod1.cpp then (once all modules are compiled) linked together g++ -o myprog mymod1.o mymod2.o ....
Even if you compile and link with a single command g++ -o myprog mymod1.cpp mymod2.cpp behind the scene g++ handle each module as single object.
I think is important you understand that each module/object know nothing about others, and if you need some other module (your main.cpp) to know something about mymod1.cpp a header file is required .h .hpp (mymod1.h) with the declarations needed to be shared: module global variables, defines, enums, function prototypes or class declarations, then just include mymod1.h in the module(s) where you want to use something of your mymod1 implementation (main.cpp).
Also, you write you're using a shell script to build, that's ok if your project are few files, better would be to use something like make, learn how to use it will require some time but then I bet geany have some facility to build projects based on Makefiles, make is the way to handle C/C++ projects from a long time.
I'm facing difficulty in understanding source and header files stuff.
Suppose
1)I have a source file(functions.cpp) which contains function named 'int add(int x,int y)' in the location /Users/xyz/Desktop/functions.cpp.
2)The header file(functions.h) which contain the declaration of the functions in source file(functions.cpp) is placed in /Users/xyz/Documents/function.h
3)Other source file(main.cpp) which contain 'main()' function need to call the 'add()' function defined in 'functions.cpp'.The source file 'main.cpp' is located in /Users/xyz/Downloads/main.cpp
I'm placing these files in different locations so that i can understand these concepts better.
So,how do i link function.cpp to main.cpp using functions.h.
#include " "
What is the path that i should use in the above include?
Also,it is my understanding that .h files provides the declaration of functions which are defined some where else and having a declaration is necessary for the compiler to call the functions which are defined in some other files or functions which are not defined yet. Is that right? Please correct me in case I'm wrong.
#include "functions.h"
Your code should not know about how you choose to arrange your source tree. To hard-code paths is to earn the hatred of whoever has to maintain this code (and that includes you six months from now).
Your build system -- whatever it is -- can deal with the paths. That could be as simple as:
g++ -I/Users/xyz/Documents -c functions.cpp
Your statement of how declarations/definitions work is basically correct.
Your first question has no answer. C++ does not define how header files are found, it's up to the compiler and they all do it a bit differently. If you want an answer you'll have to look up the details in the documentation of your compiler. I would recommend you put everything the same directory and stop worrying about it.
In the second part of your question, your understanding seems pretty good to me.
You should include in your main the exact path to your header file:
#include "/Users/xyz/Documents/function.h"
Hope this help.
Regards.
You include functions.h in functions.cpp and main.cpp using #include then you compile both main.cpp and functions.cpp. The linker then links the two resulting object files. Your inclusion of functions.h in main.cpp will allow you to call the functions from functions.h within your main.cpp file
As for paths of files, provided that you specify to your compiler the required paths in which to find your code you should be fine.
You can either use a full path
#include "/Users/xyz/Documents/function.h"
or a relative path (which is usually more preferable)
#include "../Documents/function.h"
Don't forget to specify full or relative paths to your .obj files when you are linking the final executable as well ;)
I'm working under Visual Studio 2008, maybe that's important.
In a larger project I decided to split one of my .cpp files into two. As I moved some of the functions to a new file, let's call it new.cpp, and tried to compile, I got errors that new.cpp doesn't know definitions of fstreams, setw(), etc. Now, at the very top of the new file I included my own header, let's call it main_header.h, which in turn includes all the necessary <iostream>, <iomanip>, etc. This works just fine all throughout older files used in this project, but for some reason doesn't in new.cpp.
If I add
#include <fstream>
#include <iomanip>
// and all the rest
in new.cpp then all works just fine, but that's not how I want to solve it.
I thought maybe content of main_header.h doesn't get appended to new.cpp on compilation, but that's not true, I tried using in new.cpp an external variable declared in main_header.h and defined in yet different .cpp, and got no errors on compilation, linking, or running. Yet it seems like <fstream> and <iomanip> included in main_header.h do not make it to new.cpp file.
I'm relatively new to Visual Studio, so the solution to my problem is likely something silly I'm not aware of, but I spent a good while trying to figure this one out and to no avail. The new file is definitely part of the project, since building projects attempts to compile it, plus once I include iostream and iomanip in this new.cpp I can call its routines in other parts of the project. Any ideas what I might be doing wrong?
main_header.h looks like that
#ifndef MAIN_HEADER
#define MAIN_HEADER
#include <iomanip>
#include <fstream>
// loads of other stuff
#endif // for MAIN_HEADER
Update: Ok, so the day after I created a whole new project using the same files and now all works fine, I don't need to include iomanip nor anything else in new.cpp. It sure as heck was to do with some oddities of VS not code itself, but still beats me what exactly was the issue.
This could be caused by prefix headers or precompiled headers, which can be set across the whole project, or could be set just on your new.cpp file, which might explain why there's some difference. Here's a few things to try:
Properties -> C++ -> Precompiled headers: check the setting for the whole project and for the individual files
Properties -> C++ -> Advanced -> Force includes: check this is the same for both
Open the vcproj file in a text editor and find the new.cpp node -- this is a quick way of finding if this individual file has different compiler settings
Properties -> C++ -> Preprocessor -> Generate Preprocessed file: this will generate an intermediate new.i file with all #includes and macros resolved. Compare the result of this for both files and look for the diffs -- this might show why one works and the other doesn't
Do you have another header somewhere that also has #define MAIN_HEADER?
It's an easy mistake to make when creating a new header by copying an old one, and leads to mysterious symptoms like this.