Multiple definition of several functions in two different .o files. - c++

Basically I have lots of errors like these:
IMU/IMU.cpp.o: In function `MPU6050::dmpInitialize()':
Projects/Arduino/libraries/IMU/MPU6050_6Axis_MotionApps20.h:281: multiple definition of `MPU6050::dmpInitialize()'
Quadcopter.cpp.o:Projects/Arduino/libraries/IMU/MPU6050_6Axis_MotionApps20.h:281: first defined here
But im not sure how to solve this. I have lookes into several other similar questions but didnt fint any answer related to this code.
.ino
#include <Wire.h>
#include <IMU.h>
IMU imuController;
void setup() {
Wire.begin();
imuController.init();
}
IMU.h
#include "MPU6050_6Axis_MotionApps20.h"
MPU6050_6Axis_MotionApps20.h
#include "I2Cdev.h"
#include "helper_3dmath.h"
#include "MPU6050.h"
#include <avr/pgmspace.h>
MPU6050.h
#include "I2Cdev.h"
#include <avr/pgmspace.h>

It might be because you header file is included multiple times. What you can do is define guards like this:
#ifndef SOMEVAR - *make sure the file is included only once in the current scope*
#define SOMEVAR
//Symbol definitions
#endif
or you could include #pragma once in your header file, if your compiler supports it.

As W.B suggested, you need include guard for every header file you define.
Something like
Ex: Header.h
#ifndef HEADER_H
#define HEADER_H
// Header stuff in here...
#endif

This is 7 years way too late, but here's what I did
In my own mpu_sensor.h file, I only included
#ifndef MPU_SENSOR_H
#define MPU_SENSOR_H
#include "MPU6050.h"
#include "helper_3dmath.h"
....
#endif
Note that I don't MPU6050_6Axis_MotionApps20, since most datatypes are
In my mpu_sensor.cpp file, here's my includes:
#include "MPU6050_6Axis_MotionApps20.h"
#include "mpu_sensor.h"
Please note that MPU6050_6Axis_MotionApps20.h must be before my including my own header file.
It works now.
I agree that the library itself should be updated, but it seems like the author is not updating for the past few years.

Related

Can a macro redefinition be applied to single cpp file?

I'm using rapidjson, which is an all header library. In rapidjson.h, there is a macro RAPIDJSON_ASSERT, in one of my cpp files, I would like to redefine it, so I have this code at the top of my file:
#include "stdafx.h" // for windows
#pragma push_macro("RAPIDJSON_ASSERT")
#define RAPIDJSON_ASSERT(x) if(!(x)) throw std::logic_error("rapidjson exception");
#include "rapidjson/rapidjson.h"
#include "rapidjson/document.h"
#include "rapidjson/stringbuffer.h"
#include "rapidjson/writer.h"
....
....
#pragma pop_macro("RAPIDJSON_ASSERT")
Here is the whay that rapidjson.h defines RAPIDJSON_ASSERT:
#ifndef RAPIDJSON_ASSERT
#include <cassert>
#define RAPIDJSON_ASSERT(x) assert(x)
#endif // RAPIDJSON_ASSERT
The documentation states that to override the RAPIDJSON_ASSERT logic, you just have to define RAPIDJSON_ASSERT before you include any of the files.
The issue is that when I run the code in the debugger, RAPIDJSON_ASSERT is not being redefined. I checked stdafx.h for anything which would include the rapidjson header files, and there isn't anything.
I was under the assumption that each compilation unit should run through the header files.
Note that if I move the redefinition of the macro into stdafx.h I get the macro redefined, but I was hoping to be able to do it per compilation unit.
It seems like you want to change the definition of RAPIDJSON_ASSERT for the rapidjson code itself
If so, you need to add a #define after the place where it is defined. Unless you want to edit the rapidjson.h file, the only alternative is to do this:
#include "stdafx.h" // for windows
// One would assume that the macro gets defined somewhere inside here
#include "rapidjson/rapidjson.h"
// Compiler will complain about macro redefinition without this #undef
#undef RAPIDJSON_ASSERT
#define RAPIDJSON_ASSERT(x) if(!(x)) throw std::logic_error("rapidjson exception");
#include "rapidjson/document.h"
#include "rapidjson/stringbuffer.h"
#include "rapidjson/writer.h"
Now the definition of RAPIDJSON_ASSERT is changed for the rest of the header files. You don't need the push_macro and pop_macro shenanigans - macros only are valid for each unit
Note that it's not a a good thing to redefine things for libraries using #define

For clarity's sake should you include everything already included in a .h file in the .cpp file?

Let's say I have some .h file
random.h
#ifndef RANDOM_H
#define RANDOM_H
#include <list>
#include <vector>
#include <string>
class Random {
std::vector<std::list<std::string> > m_vectorList;
}
#endif
in the corresponding cpp file should I also
#include <list>
#include <vector>
#include <string>
so that whoever is working on the implementation doesn't need to look back to the header file, or is it bad practice to include it twice?
Basically there's no point as doing this even as a time saver because:
The programmer needs to look into the header files. Actually, header files are the first files I am looking into when discovering a new program. - Basile Starynkevitch
Not only is it bad practice, it will throw a compiler error if the header files don't have include guards (#ifndef/#define/#endif).
You are defining a new header. so you need not include pre defined header twice. It's logical. Although you can include pre defined header either in new header file or .cpp file. Also it will throw a compiler error if you defined it twice because of #ifdef condition.
#define
#ifdef
#endif
#ifndef
#define
#endif

How to enforce a header file at the forefront?

Motivation:
I want to enable the memory detection of VC++, which requires that some statements must be at the forefront as follows:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
Question:
Suppose I have a header file forefront.h, what I want is the following effect:
a.cpp
#include <any_other_one.h>
#include <forefront.h> // An compiler error generated here!
b.cpp
#include <forefront.h> // OK
#include <any_other_one.h>
How to implement?
Create your own header file with the following contents:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
Now use the Forced Includes setting in the Advanced section of the project's settings. Any file specified there will be included before all others, in the order specified.
Since what you're really asking is how to ensure _CRTDBG_MAP_ALLOC is defined in all compilation units, use the VC++ project system to add that definition. Go to the project properties dialog, and in the C++ Preprocessor section add _CRTDBG_MAP_ALLOC to the Preprocessor Definitions line.
I think this is the most non-intrusive solution I come up with,
put the following at the beginning of forefront.h,
#if (__LINE__ != 0)
#error ERROR_FORE_FRONT_IS_NOT_THE_FIRST_TO_INCLUDE
#endif
you don't need to change others.h.
I tested this code with GCC 4.6.3.
I guess something like this might work:
other.h
#ifndef OTHER_H_
#define OTHER_H_
...
#endif
forefront.h
#ifdef OTHER_H_
#error Wrong include order
#endif

Header guards for bigger projects

I understand what a header guard is but I never saw how it is used in bigger projects. I am currently writing an OpenGL abstraction layer and I mostly need to include the same files.
So my first naive approach was to do something like this:
#ifndef GUARD_H
#define GUARD_H
#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <GL/glfw3.h>
#include <glload/gl_core.h>
#include <glload/gll.h>
#endif // GUARD_H
So I can just do #include "guard.h". But I realized that this is not a really good solution because what if I want to add a simple include?
Yes I probably could write all my includes in this file but I am also not sure if this is a good idea either.
How would you recommend me to structure my header guards? Can you recommend me any resources?
Update 1: small example
test.h
#ifndef TEST_H
#define TEST_H
#include <glm/glm.hpp>
class test{
};
#endif
test1.h
#ifndef TEST1_H
#define TEST1_H
#include <glm/glm.hpp>
class test1{
};
#endif
now I included glm in my test class. but what if I want to do something like this.
#include "test.h"
#include "test1.h"
int main(){
//...
}
Don't I include #include <glm/glm.hpp> 2 times in main?
It's not a good idea to put all your includes in one files, except if you always include all those file.
You should only include the strict minimum of required headers in your own headers and include the rest directly in your .cpp source files.
Each of your headers should have a unique header guard without conflict with any other library, so take a very good care of the naming scheme.
You may also consider using the non-standard #pragma once directive, if you're not writing portable code.
You could take a look at this paper about the best practice for designing header files
To answer your edit :
No you don't include <glm/glm.hpp> twice, because it has itself a header guard. But you should include it only if you actually need glm.hpp inside your header, otherwise you should include it later. Note that you can often avoid the include by forward-declaring what you need, that could speed-up the compilation and avoid circular dependency, but that's another issue.
Simple. Header guards in every single header.
The way you've done it is unsafe : What if one day someone (not necessarily you, though even this is unsure) includes directly one of the headers you listed (though these are mostly external libs it seems, but it could evolve to include one of yours...), and this header doesn't have include guards ? Might as well exclude this possible issue ASAP !
To structure your headers, you should prefer to include what is strictly needed rather than everything in one global header.
Edit answer : No you won't include it twice. After the first include, every extra occurrence of the header guarded file will simply be ignored.

refactoring my code. My headers (Header Guard Issues)

I had a post similar to this awhile ago based on a error I was getting. I was able to fix it but since then I been having trouble doing things because headers keep blocking other headers from using code. Honestly, these headers are confusing me and if anyone has any resources that will address these types of issues, that will be helpful.
What I essentially want to do is be able to have rModel.h be included inside RenderEngine.h. every time I add rModel.h to RenderEngine.h, rModel.h is no longer able to use RenderEngine.h. (rModel.h has a #include of RenderEngine.h as well).
So in a nutshell, RenderEngine and rModel need to use each others functionalities. On top of all this confusion, the Main.cpp needs to use RenderEngine.
stdafx.h
#include "targetver.h"
#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers
// Windows Header Files:
#include <windows.h>
// C RunTime Header Files
#include <stdlib.h>
#include <malloc.h>
#include <memory.h>
#include <tchar.h>
#include "resource.h"
main.cpp
#include "stdafx.h"
#include "RenderEngine.h"
#include "rModel.h"
// Global Variables:
RenderEngine go;
rModel *g_pModel;
...code...........
rModel.h
#ifndef _MODEL_H
#define _MODEL_H
#include "stdafx.h"
#include <vector>
#include <string>
#include "rTri.h"
#include "RenderEngine.h"
........Code
RenderEngine.h
#pragma once
#include "stdafx.h"
#include "d3d10.h"
#include "d3dx10.h"
#include "dinput.h"
#include "rModel.h"
.......Code......
As I wrote in my previous answer on this question, google about Forward declaration in C++.
This may solve your problems, but, again, circular header dependencies indicate poor application design.
At least if I understand your question correctly, you have a little bit of a problem. You basically need to structure your headers so the inclusions form a directed acyclic graph (emphasis on acyclic).
What you may have to do is break your "renderengine.h" into two pieces, one of which just contains forward declarations, and the other of which contains the rest of your current contents. You'll then include that "forward declarations" header into "rmodel.h", and include "rmodel.h" into "renderengine.h".
While there are times that this is unavoidable, such a circular dependency often points to a problem with how you've organized your modules. It's entirely possible that what you currently have as renderengine.h and rmodule.h should be a single header, or perhaps multiple headers but broken along different lines.