I have a main file main.cpp which include myclass.h. I also have myclass.o and myclass.cpp. The visual studio project is only using the files main.cpp and myclass.h.
This compile:
#include "myclass.h"
int main()
{
return 0;
}
This does not:
#include "myclass.h"
int main()
{
myclass M{};
return 0;
}
which gives a link error - probably because the myclass.cpp or myclass.o is not included in the project.
I would prefer to include only myclass.o since compiling this class is very problematic.
See
https://forum.qt.io/topic/8492/solved-cannot-get-quazip-test-to-work/3
if you are curious of which library I am using.
To my question:
Can I compile and use the class with only the header and the object file, i.e without the .cpp file at all?
Thanks!
Visual Studio generates a .obj file as its intermediate format. gcc and gcc are the ones that produce a .o file. You can include this in your project or, since libraries rarely have a single compile unit, you can build a .lib file and include that. Be warned, though, that the compiled units must be compiled using the exact same compiler switches such as run time library and etc. as you are using in you project. It is often simpler to simply compile the file from source.
We can also talk about using a DLL but that seems to be beyond the scope of your question and also introduces the complication of calling conventions.
Related
I am a C++ learner and I came across a concept of separating code into multiple files to speed up compiling process on bigger projects.
However what the book doesn't tell me and I have tried to find it in other books and on the web, but with no luck is how does linker (during compilation) knows what files to include.
When I make new file I connect its header to the main file with #include "newfile.h", however in this header I don't write where to find definitions of functions.
So how I imagine the process is that it starts in the main file and there it finds "connections" to other files. The question is how it finds those .cpp files that as far as I see don't need to be named the same as its header file.
Exmple:
Main file:
#include <iostream>
#include "krneki_H.h"
using namespace std;
int main()
{
krneki1();
krneki2();
krneki3();
}
And header file:
void krneki1();
void krneki2();
void krneki3();
And new .cpp file:
#include <iostream>
#include "krneki_H.h"
using namespace std;
void krneki1() {
cout<<"Krneki1"<<endl;}
void krneki2() {
cout<<"Krneki2"<<endl;}
void krneki3() {
cout<<"Krneki3"<<endl;}
Notice that there is no indication to use second cpp file. It just knows to use it. Does it search all .cpp files in the map?
Thank you for answer.
You compile both .cpp files using gcc -c or a similar command line, and then pass both of the .o files produced to the linker. The linker does not magically figure out that you want to compile another .cpp file.
For example
gcc -c main.cpp -o main.o # compile
gcc -c krneki_H.cpp -o krneki_H.o # compile
gcc main.o krneki_H.o -o main # link
Your IDE may take care of these details automatically, in which case it compiles all .cpp files you added to your project, then links all the .o files produced by the compilation step.
No. It doesn't just know to use it. In your example, if you compile with main.cpp and without that new cpp file, you'll get an "undefined reference" error.
What happens is that you're using a fancy IDE that automatically compiles all cpp files. It includes them all by default in your makefile.
I recommend that you try to design a makefile from scratch, and see for yourself how you'll get that "undefined reference" error if you don't include the cpp file that has the implementations of your functions.
I don't really understand the why behind this, but I think I've figured out the what.
My brother is working on a homework project and they're using Visual Studio. He was having issues getting his project to compile. The project in question consisted of:
main.cpp
classes.h
class_functions.cpp
general_functions.cpp
They had the following import structure:
main.cpp
#include "classes.h"
#include "class_functions.cpp"
#include "general_functions.cpp"
class_functions.cpp
#include "classes.h"
general_functions.cpp
#include "classes.h"
He kept getting link errors when trying to compile, even though g++ would compile it just fine. So I tried via Visual Studio command prompt and cl. This compiled just fine, so I tried msbuild which (obviously?) failed. I went into the vxproj file, because hey, what is it telling cl that I'm not?
In the proj file it was including classes.h, general_functions.cpp and class_functions.cpp, as well as main.cpp. When I removed general and class functions, msbuild ran just fine. Put either of them back and boom. classes.h contains
#ifndef myclasses
#define myclasses
/* Code here */
#endif
And the other .cpp files contain similar directives.
I finally figured out how to eliminate the problem - eliminate
#include "general_functions.cpp"
#include "class_functions.cpp"
from the code base, and now Visual Studio compiles this just fine.
The question is why? What is the justification or possible benefits from doing this?
the difference between .cpp and .h files is that the .h files are usually included with the #include directive while .cpp files are included in the linking process.
The #include instruction will insert a copy of the included file in the code you are compiling, so by including the .cpp files you will compile a single source file that contains all your .cpp files. It's very bad practice but still could work.
But if you are then adding the .cpp files also in the linking step then you are adding those files a second time creating probably duplicate definitions of your functions, e.g. linker error. I think that's probably the main error (without the linker error codes I'm just guessing).
The problem I am having is that, when I call a constructor for a class I have created I get the following error.
main.cpp:20: undefined reference to
`StaticObject::StaticObject(Graphics*, sf::String,
sf::Vector2)'
This problem can be 'fixed' adding an include for the .cpp file in main.cpp like so.
...
#include "GameObjects/StaticObject.cpp"
...
Although this solves the problem, this seems like a poor solution and goes against what I have been previously told. Is there any other way to solve this problem? I'm using Netbeans 7.3 with g++ to code/compile this program. Below is the relevant code.
main.cpp
...
#include <SFML/Graphics.hpp>
#include "Graphics/Graphics.hpp"
#include "GameObjects/StaticObject.hpp"
int main(int argc, char** argv) {
//SETUP
Graphics graphics;
background = new StaticObject(&graphics, "Data/Images/BackgroundPlaceholder.png", sf::Vector2f(0,0));
...
main.hpp
...
#include <SFML/Graphics.hpp>
#include "GameObjects/StaticObject.hpp"
...
// Objects
StaticObject *background;
...
StaticObject.hpp
#include <SFML/Graphics.hpp>
#include "../Graphics/Graphics.hpp"
class StaticObject{
public:
StaticObject();
StaticObject(Graphics *_graphics, sf::String texture_filename, sf::Vector2f _position);
StaticObject(const StaticObject& orig);
virtual ~StaticObject();
private:
// The sprite stores the position
sf::Sprite *sprite;
sf::Texture *texture;
};
StaticObject.cpp
#include "StaticObject.hpp"
#include <SFML/Graphics.hpp>
#include "../Graphics/Graphics.hpp"
StaticObject::StaticObject(){
}
StaticObject::StaticObject(Graphics *_graphics, sf::String texture_filename, sf::Vector2f _position) {
sprite = _graphics->AddSprite(texture_filename);
sprite->setPosition(_position);
}
StaticObject::StaticObject(const StaticObject& orig) {
}
StaticObject::~StaticObject() {
}
If I add the following line to main.cpp, the error disappears.
#include "GameObject/StaticObject.cpp"
Can anyone please explain:
Why this fixes the problem?
Why the .cpp was not implicitly included through including the .hpp
file?
Is there a better way of doing this?
The undefined reference error indicates that the definition of a function/method (i.e constructor here) was not found by the linker.
StaticObject::StaticObject(Graphics*, sf::String, sf::Vector2<float>)
And the reason that adding the following line:
#include "GameObject/StaticObject.cpp"
fixes the issue, is it brings in the implementation as part of the main.cpp whereas your actual implementation is in StaticObject.cpp. This is an incorrect way to fix this problem.
I haven't used Netbeans much, but there should be an option to add all the .cpp files into a single project, so that Netbeans takes care of linking all the .o files into a single executable.
If StaticObject.cpp is built into a library of its own (I highly doubt that is the case here), then you might have to specify the path to the location of this library, so that the linker can find the implementation.
This is what ideally happens when you build your program:
Compile: StaticObject.cpp -> StaticObject.o
Compile: main.cpp -> main.o
Link: StaticObject.o, main.o -> main_program
Although there are ways in gcc/g++ to skip all the intermediate .o file generations and directly generate the main_program, if you specify all the source files (and any libraries) in the same command line.
The linker cannot find the definition for StaticObject, which means you have not compiled and linked StaticObject.cpp. Each .cpp file needs to be separately compiled, and the object files the compiler produces for each one needs to be given to the linker.
The reason including StaticObject.cpp in Main.cpp works is that you are telling the preprocessor to insert the contents of StaticObject.cpp into Main.cpp, which you are compiling, so the definitions become part of Main.cpp's compiled output.
including the cpp file causes the compiler to build that code as part of that file (which you should not do), what you need to do is compile the GameObject/StaticObject.cpp file as its own object, and link the 2 objects together.
I dont know much of netbeans, but probably GameObject/StaticObject.cpp is not included as part of the sources to compile.
That's why if you include it manually at main.cpp he found source code and everything is ok.
I had the same issue but mine was because I'm using Eclipse CDT with and Autotools project. So I had to manually add the new .h and .cpp files to the corresponding Makefile.am, and then do a project > reconfigure project, rebuild, an that was it.
I had the same issue in Qt, where I forgot to add the class to the pro file. Apparently, without adding it to the pro file, the compiler doesn't recognize it. So I added it in, and then ran qmake again, and that silved the problem.
Basically, you need to add the file in the sources.
My project has this folder structure:
Project/
--Classes/
----Class1.h
----Class1.cpp
--main.cpp
"Class1.h" contains method definitions, "Class1.cpp" is the source code for "Class1.h".
The source code of "Class1.h" is like this:
class Class1 {
public:
void do_something();
};
The source code of "Class1.cpp" is like this:
#include "Class1.h"
void Class1::do_something() {
//
}
The source code of "main.cpp" is like this:
#include "Classes/Class1.h"
int main(int argc,char** args) {
Class1* var = new Class1();
var->do_something();
return 0;
}
However, when compiling "main.cpp", the compiler doesn't know where the implementation of methods in Class1 is, so it shows linking error about undefined reference.
Do I have to add any path into the command line so the compiler knows what source files it has to compile? How to tell the compiler that it must compile "Class1.cpp" also?
You need to feed all files in your project to the compiler, not just "main.cpp". Here you can read about the basics of compiling multiply files together with Gcc.
Another option would be to compile your classes as a dynamic or static library, but you should start with simply compiling them together if you're not quite familiar with libraries.
You need to know about building (compiling and linking) C++ applications. This topic usually don't describe in programming books about C++ and only way to do it - google and programming community sites with articles.
Fast answer is:
g++ -c Classes/Class1.cpp -o Class1.o
g++ -c main.cpp -o main.o
g++ Class1.0 main.0 -o ProjectName
It's a simple set of commands to compiling and linking program. Usually it would be done by build system (make, qmake, cmake, waf, scons, ant etc). Also, IDE can build program without additional configuration, Visual Studio for example.
The correct way to do it is doing the header inclusion in the Class1.cpp file. That way if the Class1.cpp is compiled as a library, you can use the header file to get the declarations.
The other way around, if you will directly use the Class1.cpp, compiling it with your project. You should include Class1.cpp in your main.cpp.
quick question.
I am trying to get C++ nailed down, and today I spent hours with a double definition linker error("this has already been defined!") and I finally realised it's because I had the layout as such:
main.cpp
#include Dog.cpp
Dog.cpp
#include Dog.h
Dog.h
// (Dog class and prototype of test function)
And now that I've cleared that up by including the Dog.h instead of the Dog.cpp in the main.cpp.
By including the .h file, does the .cpp file with the identical prefix get compiled with the program?
I was astounded when the program ran with only the .h included and no references whatsoever to Dog.cpp. I spent ages Googling but no answers really helped me understand what was going on.
Edit: I forgot to add that I prototyped in the .h, and defined the function for the class in the .cpp and that's what gave me the "already defined" error.
By including the .h file, does the .cpp file with the identical prefix get compiled with the program? I was astounded when the program ran with only the .h included and no references whatsoever to Dog.cpp.
No.
Your program is built in phases.
For the compilation phase, only declarations are needed in each translation unit (roughly equivalent to a single .cpp file with #includes resolved). The reason that declarations even exist in the first place is as a kind of "promise" that the full function definition will be found later.
g++ -c Dog.cpp # produces `Dog.o`
g++ -c main.cpp # produces `main.o`
For the linking phase, symbols are resolved between translation units. You must be linking together the result of compiling Dog.cpp and of compiling main.cpp (perhaps your IDE is doing this for you?), and this link process finds all the correct function definitions between them to produce the final executable.
g++ Dog.o main.o -o program # produces executable `program`
(Either that, or you actually haven't got to the link phase yet, and merely have an object file (Dog.o); you can't execute it, partially because it doesn't have all the function definitions in.)
The two phases can be done at the same time, with the "shorthand":
g++ Dog.cpp main.cpp -o program # compiles, links and produces executable
No, the .cpp file does NOT automatically get compiled. You can either do that manually, create a makefile, or use an IDE that has both of them in the same project.
You don't specify how you are compiling it. If you are using an IDE and have a new .h and .cpp to the project automatically then it will all be compiled and linked automatically.
There are 2 stages to making an executable to run: compiling and linking. Compiling is where the code gets interpretted and translated into lower level code. Linking is where all of the functions that you used get resolved. This is where you got the duplicate function error.
Inclusion does not automatically cause compilation, no.
In fact, the actual compiler never sees the #include statement at all. It's removed by an earlier step (called the preprocessor).
I'm not sure how it could build if you never compiled the Dog.cpp file. Did you reference any objects with code defined in that file?