including and excluding at compiletime

Discussion in 'C++' started by Al-Burak, Dec 18, 2005.

  1. Al-Burak

    Al-Burak Guest

    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)
    Al-Burak, Dec 18, 2005
    #1
    1. Advertising

  2. Al-Burak schrieb:
    > 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 */};
    >

    <snip>
    > --- manipulator.hpp ---
    > #ifndef MANIPULATOR_HPP
    > #define MANIPULATOR_HPP
    > #ifdef POPEYE_HPP
    > #include "popeye.hpp"


    This has no effect. Do you understand the inclusion guards?

    > #endif

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

    <snip>
    > --- 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
    Thomas J. Gritzan, Dec 18, 2005
    #2
    1. Advertising

  3. Al-Burak wrote:

    > 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?


    --
    Nick Keighley
    Nick Keighley, Dec 18, 2005
    #3
  4. Al-Burak

    Jim Langston Guest

    "Al-Burak" <> wrote in message
    news:...
    >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.

    > --- 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)
    >
    Jim Langston, Dec 18, 2005
    #4
  5. Al-Burak

    Al-Burak Guest

    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



    Jim Langston wrote:
    > "Al-Burak" <> wrote in message
    > news:...
    > >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.
    >
    > > --- 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)
    > >
    Al-Burak, Dec 19, 2005
    #5
  6. Al-Burak

    Guest

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

    Al-Burak wrote:
    > Jim Langston wrote:
    > > "Al-Burak" <> wrote in message
    > > news:...
    > > > --- 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"
    > > > #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.
    > >
    > > >
    > > > class manipulator{
    > > > private:
    > > > ..........
    > > > protected:
    > > > ..........
    > > > public:
    > > > ..........
    > > > #ifdef POPEYE_HPP
    > > > void handle_popeye(const popeye&);
    > > > #endif
    > > >
    > > > };
    > > > #ifdef POPEYE_HPP
    > > > void manipulator::handle_popeye(const popeye& p){/*...*/}
    > > > #endif

    > >
    > > Extemely ugly code and prone to maintainence nightmares. I would find some
    > > other way to do this.
    > >
    > > > --- main.cpp --
    > > > #include "popeye.hpp"
    > > > #include "manipulator"


    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.

    > > > 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?
    > > >

    > 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
    , Dec 19, 2005
    #6
  7. Al-Burak

    Al-Burak Guest

    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! ;)
    Al-Burak, Dec 19, 2005
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Olav Tollefsen
    Replies:
    2
    Views:
    354
    Olav Tollefsen
    Feb 1, 2005
  2. Arne Adams

    ANN: reflection at compiletime

    Arne Adams, Jul 28, 2004, in forum: C++
    Replies:
    3
    Views:
    369
    Peter van Merkerk
    Jul 29, 2004
  3. Christof Warlich
    Replies:
    4
    Views:
    311
    Christof Warlich
    Aug 9, 2008
  4. Replies:
    12
    Views:
    805
    Vidar Hasfjord
    Dec 24, 2008
  5. Christoph Mathys
    Replies:
    14
    Views:
    594
    Tech07
    Sep 16, 2009
Loading...

Share This Page