Go Down

Topic: IDE - Ignoring '#ifndef' directive ?? (Read 145 times) previous topic - next topic


Using IDE 1.6.5 R2 I'm getting frustrated by ': multiple definition of ' type errors for a library .h file that has a conditional header i.e

#ifndef XYZ_H
#define XYZ_H



so I include <xyz.h> in my app, I also include "xyz.h" in my library class xyz.cpp file - and yet at compile time the IDE bitches about duplicate definition of items - which there shouldn't be if it was obeying the #ifndef directive.

Am I missing something here - I thought the purpose of #ifndef was to prevent multiple inclusion of code or definitions.

Once Only Headers - GCC


Am I missing something here
Yes, indeedy - your code!


I have it up elsewhere - should have linked - I'm currently messing around with definition locations but it is attached.

I've tried a few ways to handle the 'globals' as I am trying to avoid wasting space - i.e. a local .h in my application with 'extern' definitions but when I tried this the code didn't work - compiled but didn't work.

I think the library needs more autonomy though with less 'shared' - but again I'm trying to save space as a lot more will be going into this.  I'm just trying to 'relocate' variable definitions at the moment.

This is a combination of trying to understand how the code author was thinking, learning the math side of things and also building coding skills.


This is well known problem with IDE mutilating preproccessor directives in x.ino file.
It really acts differently in different releases.
In 1.6.6 older nightly build I am using I cannot use system (<system file>) includes in ANY "local" header files.
The system includes have to be in the main x.ino , but the local ("header file" ) are included properly no matter where they are.
Your mileage will vary.


I have moved stuff around and modified some of the function calls and now it compiles - but I still think there's a defect here based on everything I've read elsewhere.

The compiler should not be including anything inside #ifndef if the condition is not true - i.e. the block is already defined - regardless of what is there it should be created only once.


Where is the sketch that uses the header file?

Where are the error messages?


That sketch no longer exists, things have moved on.

Basically any ino that loads the library as posted i.e. MPU9150.h / MPU9150.cpp will show the error on my set up.


That sketch no longer exists, things have moved on.
You've changed the code. You don't like what you had to do, but you did not explain what you did, or why you don't like it. And, yet you don't want to post all of the code. Moving on seems like a really good idea.


"Moving on seems like a really good idea"
I don't get the attitude, not the first time I've encountered it here, I explained what I was doing and what I did - moving stuff around and changing functions

The original ino doesn't matter, even a basic ino containing only a reference to the library will show the compilers disregard of the directive.


Just what I suspected from the start even before seeing the code.
Variable definitions in a header file.


Code: [Select]

uint8_t Ascale = AFS_2G;     // AFS_2G, AFS_4G, AFS_8G, AFS_16G
uint8_t Gscale = GFS_250DPS; // GFS_250DPS, GFS_500DPS, GFS_1000DPS, GFS_2000DPS
float aRes, gRes, mRes;      // scale resolutions per LSB for the sensors

(and a lot more)

Of course you are going to get complaints about duplicate symbols, if you include this in two or more source files that are linked together.


Not ideal granted but why would they even be 'processed' if they are within an #ifndef #endif directive and have been defined once.


The source files are compiled separately. The header file has not been "already included" during each compilation.


Ah - so it is only #ifndef for the current file not for the project as a whole ... makes sense I guess.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131