including and excluding at compiletime

A

Al-Burak

I have a class which only purpose is to provide services to a variety
of classes in other files. The 'manipulator' class is aware of the
other classes only because the header files have been include in its
header file. However, there are times when some of the other classes
are not and will not be dealt with, thus the need to include the header
files does not arrive. To handle this, I have used compiler
preprocessors to prevent the unneeded header files and method
declarations / implementations to be compiled, here is an example:

--- popeye.hpp ---
#ifndef POPEYE_HPP
#define POPEYE_HPP
class popeye{ /*the whole enchilada goes here */};

--- mikey.hpp ---
#ifndef MIKEYMOUSE_HPP
#define MIKEYMOUSE_HPP
class mikey{ /*more cheese senior?*/ };

--- donal.hpp ---
#ifndef DONALDUCK_HPP
#define DONALDUCK_HPP
class duck{ /* para bailar la banba */};

--- manipulator.hpp ---
#ifndef MANIPULATOR_HPP
#define MANIPULATOR_HPP
#ifdef POPEYE_HPP
#include "popeye.hpp"
#endif
#ifdef MIKEYMOUSE_HPP
#include "mikey.hpp"
#endif

#ifdef DONALDUCK_HPP
#include "donal.hpp"
#endif

class manipulator{
private:
..........
protected:
..........
public:
..........
#ifdef POPEYE_HPP
void handle_popeye(const popeye&);
#endif

#ifdef MIKEMOUSE_HPP
void handle_mikey(const mikey&);
#endif

#ifdef DONALDUCK_HPP
void handle_duck(const duck&);
#endif
.........
};
#ifdef POPEYE_HPP
void manipulator::handle_popeye(const popeye& p){/*...*/}
#endif
#ifdef MIKEMOUSE_HPP
void manipulator::handle_mikey(const mikey& p){/*...*/}
#endif
#ifdef DONALDUCK_HPP
void manipulator::handle_duck(const duck& p){/*...*/}
#endif
--- main.cpp --
#include "popeye.hpp"
#include "manipulator"

int main(){
popeye p;
manipulator m;
m.handle_popeye(p); //<<== Segmentation Fault
return 0;
}

My question is: why is it that if I remove the conditional
preprocessors I don't get a segmentation fault?


T. I. A. F.
(Thank In Advance Folks)
 
T

Thomas J. Gritzan

Al-Burak said:
I have a class which only purpose is to provide services to a variety
of classes in other files. The 'manipulator' class is aware of the
other classes only because the header files have been include in its
header file. However, there are times when some of the other classes
are not and will not be dealt with, thus the need to include the header
files does not arrive. To handle this, I have used compiler
preprocessors to prevent the unneeded header files and method
declarations / implementations to be compiled, here is an example:

Really ugly design...
Didn't you know that the preprocessor is the root of all evil?
--- popeye.hpp ---
#ifndef POPEYE_HPP
#define POPEYE_HPP
class popeye{ /*the whole enchilada goes here */};
--- manipulator.hpp ---
#ifndef MANIPULATOR_HPP
#define MANIPULATOR_HPP
#ifdef POPEYE_HPP
#include "popeye.hpp"

This has no effect. Do you understand the inclusion guards?
class manipulator{
private:
..........
protected:
..........
public:
..........
#ifdef POPEYE_HPP
void handle_popeye(const popeye&);
#endif
--- main.cpp --
#include "popeye.hpp"
#include "manipulator"

int main(){
popeye p;
manipulator m;
m.handle_popeye(p); //<<== Segmentation Fault
return 0;
}

My question is: why is it that if I remove the conditional
preprocessors I don't get a segmentation fault?

Why do you expect segmentation faults? There is nothing that causes one.
You could only run into compilation errors.

What conditionals did you remove exactly?

Thomas
 
N

Nick Keighley

Al-Burak said:
I have a class which only purpose is to provide services to a variety
of classes in other files. The 'manipulator' class is aware of the
other classes only because the header files have been include in its
header file. However, there are times when some of the other classes
are not and will not be dealt with, thus the need to include the header
files does not arrive. To handle this, I have used compiler
preprocessors to prevent the unneeded header files and method
declarations / implementations to be compiled, here is an example:

--- popeye.hpp ---
#ifndef POPEYE_HPP
#define POPEYE_HPP
class popeye{ /*the whole enchilada goes here */};

--- mikey.hpp ---
#ifndef MIKEYMOUSE_HPP
#define MIKEYMOUSE_HPP
class mikey{ /*more cheese senior?*/ };

--- donal.hpp ---
#ifndef DONALDUCK_HPP
#define DONALDUCK_HPP
class duck{ /* para bailar la banba */};

--- manipulator.hpp ---
#ifndef MANIPULATOR_HPP
#define MANIPULATOR_HPP
#ifdef POPEYE_HPP
#include "popeye.hpp"
#endif
#ifdef MIKEYMOUSE_HPP
#include "mikey.hpp"
#endif

#ifdef DONALDUCK_HPP
#include "donal.hpp"
#endif

class manipulator{
private:
..........
protected:
..........
public:
..........
#ifdef POPEYE_HPP
void handle_popeye(const popeye&);
#endif

#ifdef MIKEMOUSE_HPP
void handle_mikey(const mikey&);
#endif

#ifdef DONALDUCK_HPP
void handle_duck(const duck&);
#endif
.........
};

<snip>

I don't really understand what you are trying to do. Your manipulator
class may handle popeye() objects and uses the preprocessor to
specify this. Your manipulator class potentially can handle many
classes. What exactly does manipulator do? Can't the popeye
specific stuff be moved back into the popeye class? There's gotta be
a way to do this that doesn't involve the preprocessor!

Coulr be have a more specific example?
 
J

Jim Langston

Al-Burak said:
I have a class which only purpose is to provide services to a variety
of classes in other files. The 'manipulator' class is aware of the
other classes only because the header files have been include in its
header file. However, there are times when some of the other classes
are not and will not be dealt with, thus the need to include the header
files does not arrive. To handle this, I have used compiler
preprocessors to prevent the unneeded header files and method
declarations / implementations to be compiled, here is an example:

--- popeye.hpp ---
#ifndef POPEYE_HPP
#define POPEYE_HPP
class popeye{ /*the whole enchilada goes here */};

--- mikey.hpp ---
#ifndef MIKEYMOUSE_HPP
#define MIKEYMOUSE_HPP
class mikey{ /*more cheese senior?*/ };

--- donal.hpp ---
#ifndef DONALDUCK_HPP
#define DONALDUCK_HPP
class duck{ /* para bailar la banba */};

--- manipulator.hpp ---
#ifndef MANIPULATOR_HPP
#define MANIPULATOR_HPP
#ifdef POPEYE_HPP
#include "popeye.hpp"
#endif

This isn't going to work. POPEYE_HPP is defined *inside* popeye.hpp. But
you're only including popeye.hpp if it's already defined. If it was already
defined the header would already have been included anyway so no use to
include here again.

That's kinda like saying, "If this sealed black box contains the number 42
open it. Other wise don't open it." You don't know what's inside the box
until you open it.
#ifdef MIKEYMOUSE_HPP
#include "mikey.hpp"
#endif

#ifdef DONALDUCK_HPP
#include "donal.hpp"
#endif

class manipulator{
private:
..........
protected:
..........
public:
..........
#ifdef POPEYE_HPP
void handle_popeye(const popeye&);
#endif

#ifdef MIKEMOUSE_HPP
void handle_mikey(const mikey&);
#endif

#ifdef DONALDUCK_HPP
void handle_duck(const duck&);
#endif
.........
};
#ifdef POPEYE_HPP
void manipulator::handle_popeye(const popeye& p){/*...*/}
#endif
#ifdef MIKEMOUSE_HPP
void manipulator::handle_mikey(const mikey& p){/*...*/}
#endif
#ifdef DONALDUCK_HPP
void manipulator::handle_duck(const duck& p){/*...*/}
#endif

Extemely ugly code and prone to maintainence nightmares. I would find some
other way to do this.
 
A

Al-Burak

Thanks for your prompt response Jim.
When main.cpp is compiled, popeye.hpp is included. popeye.hpp in turn
defines a variable named POPEYE_HPP.
Later the compiler finds the inclusion of 'manipulator.hpp' where the
a few questions are posted to the compiler:
Does the variable POPEYE_HPP exist?
If the variable exist, include the file popeye.hpp.
Otherwise the file is ignored.

After this question has been answered, the compiler is asked again if
the the variable POPEYE_HPP has been declared, if so, it compiles the
function declaration 'handle_popeye()', or ignore it otherwise.

Finally, in the 'manipulator.cpp' the same question is asked before
compiling the implementation of the function 'handle_popeye()'.

Then program returns to main and should process 'm.handle_popeye()'
without any problems; because, since the compiler *did find the
variable POPEYE_HPP, the method 'manipulator::handle_popeye() *was
compiled.

Now, this is how I undertand it. Am I right?


Thanks Jim
 
D

deane_gavin

Please don't top-post. Put your reply below or in-line, not above.
Rearranged. Thank you.


You have structured your code so that if you include these two the
other way round (manipulator first) you don't get the effect you want.
Every header file should be entirely self-contained. It should not be a
requirement to include other things first, in the right order, to get
them working. Otherwise, you can guarantee one day that you will get it
wrong and your program will not work.
Thanks for your prompt response Jim.
When main.cpp is compiled, popeye.hpp is included. popeye.hpp in turn
defines a variable named POPEYE_HPP.
Later the compiler finds the inclusion of 'manipulator.hpp' where the
a few questions are posted to the compiler:
Does the variable POPEYE_HPP exist?
If the variable exist, include the file popeye.hpp.
Otherwise the file is ignored.

This dependency on order of including the header files is your
maintenance nightmare.
After this question has been answered, the compiler is asked again if
the the variable POPEYE_HPP has been declared, if so, it compiles the
function declaration 'handle_popeye()', or ignore it otherwise.

Finally, in the 'manipulator.cpp' the same question is asked before
compiling the implementation of the function 'handle_popeye()'.

And does manipulator.cpp include (directly or indirectly) popeye.h?

Preprocessor symbols are not remembered between different source files.
If main.cpp includes popeye.h then main.cpp is compiled with POPEYE_HPP
defined. If manipulator.cpp does not include popeye.h then
manipulator.cpp is compiled *without* POPEYE_HPP defined, regardless of
whether it was defined when compiling main.cpp.

Gavin Deane
 
A

Al-Burak

Oooohh!
Gee, man!
Live and learn!

Thanks Gavin, thanks so much. I was really messed up on this one.

Have a good one, but if you are having more than one... call me! ;)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top