Class redefintion problem

Discussion in 'C++' started by Marcus Kwok, Mar 19, 2007.

  1. Marcus Kwok

    Marcus Kwok Guest

    The Cool Giraffe <> wrote:
    > I have the following:
    >
    > //A.h
    > class A {};
    >
    > //B.h
    > #include "A.h"
    > class B : A {};
    >
    >
    > //C.h
    > #include "A.h"
    > class C : A {};
    >
    > In my "main.cpp" I go:
    >
    > #include "B.h"
    > #include "C.h"
    >
    > and bad things happen. How do I aviod it?
    >
    > I have heard something about IFNDEF but I don??t really
    > feel competent to use it. Trial and error would be very
    > time consuming.


    The way ifndef works is, "if the following symbol is not defined, then
    do whatever". So,

    //A.h
    #ifndef A_H
    #define A_H

    class A {};

    #endif


    //B.h
    #ifndef B_H
    #define B_H

    #include "A.h"
    class B : A {};

    #endif


    and similarly for C.h. Therefore, the first time it tries to #include
    A.h, the A_H macro is not defined yet, so the first thing it does is to
    #define A_H. When A.h is included again in the same translation unit
    (your main.cpp), A_H is already defined, so it skips down to the #endif,
    jumping over the definition of class A.

    --
    Marcus Kwok
    Replace 'invalid' with 'net' to reply
    Marcus Kwok, Mar 19, 2007
    #1
    1. Advertising

  2. Marcus Kwok

    Andre Kostur Guest

    "The Cool Giraffe" <> wrote in news:568ccjF27ge49U1
    @mid.individual.net:

    > I have the following:
    >
    > //A.h
    > class A {};
    >
    > //B.h
    > #include "A.h"
    > class B : A {};
    >
    >
    > //C.h
    > #include "A.h"
    > class C : A {};
    >
    > In my "main.cpp" I go:
    >
    > #include "B.h"
    > #include "C.h"
    >
    > and bad things happen. How do I aviod it?
    >
    > I have heard something about IFNDEF but I don´t really
    > feel competent to use it. Trial and error would be very
    > time consuming.


    Use them:

    // A.h

    #ifndef INCLUDED_A_H
    #define INCLUDED_A_H

    class A {};

    #endif



    Repeat similarly for B.h and C.h (using INCLUDED_B_H and INCLUDED_C_H,
    respectively).
    Andre Kostur, Mar 19, 2007
    #2
    1. Advertising

  3. I have the following:

    //A.h
    class A {};

    //B.h
    #include "A.h"
    class B : A {};


    //C.h
    #include "A.h"
    class C : A {};

    In my "main.cpp" I go:

    #include "B.h"
    #include "C.h"

    and bad things happen. How do I aviod it?

    I have heard something about IFNDEF but I don´t really
    feel competent to use it. Trial and error would be very
    time consuming.

    --
    Vänligen Kerstin Viltersten
    (The Cool Giraffe)
    The Cool Giraffe, Mar 19, 2007
    #3
  4. The Cool Giraffe wrote:
    > I have the following:
    >
    > //A.h
    > class A {};
    >
    > //B.h
    > #include "A.h"
    > class B : A {};
    >
    >
    > //C.h
    > #include "A.h"
    > class C : A {};
    >
    > In my "main.cpp" I go:
    >
    > #include "B.h"
    > #include "C.h"
    >
    > and bad things happen. How do I aviod it?


    Three words: "double inclusion guards".

    > I have heard something about IFNDEF but I don´t really
    > feel competent to use it. Trial and error would be very
    > time consuming.


    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Mar 19, 2007
    #4
  5. Marcus Kwok wrote/skrev/kaita/popisal/schreibt :
    > The Cool Giraffe <> wrote:


    >> I have the following:
    >>
    >> //A.h
    >> class A {};
    >>
    >> //B.h
    >> #include "A.h"
    >> class B : A {};
    >>
    >>
    >> //C.h
    >> #include "A.h"
    >> class C : A {};
    >>
    >> In my "main.cpp" I go:
    >>
    >> #include "B.h"
    >> #include "C.h"
    >>
    >> and bad things happen. How do I aviod it?
    >>
    >> I have heard something about IFNDEF but I don??t really
    >> feel competent to use it. Trial and error would be very
    >> time consuming.

    >
    > The way ifndef works is, "if the following symbol is not defined, then
    > do whatever". So,
    >
    > //A.h
    > #ifndef A_H
    > #define A_H
    >
    > class A {};
    >
    > #endif
    >
    >
    > //B.h
    > #ifndef B_H
    > #define B_H
    >
    > #include "A.h"
    > class B : A {};
    >
    > #endif
    >
    > and similarly for C.h. Therefore, the first time it tries to #include
    > A.h, the A_H macro is not defined yet, so the first thing it does is
    > to #define A_H. When A.h is included again in the same translation
    > unit (your main.cpp), A_H is already defined, so it skips down to the
    > #endif, jumping over the definition of class A.



    My, my, my... I get the point and i'd like to thank you for the
    answer. However, i can't stop wondering why such utility isn't
    by default a part of the language. What can such monsterity
    (in my, beginners eyes) be useful for? I'm sure there's a
    point to that and it'd be easier to live if i knew.

    --
    Vänligen Kerstin Viltersten
    (The Cool Giraffe)
    The Cool Giraffe, Mar 19, 2007
    #5
  6. The Cool Giraffe wrote:
    > ...
    > My, my, my... I get the point and i'd like to thank you for the
    > answer. However, i can't stop wondering why such utility isn't
    > by default a part of the language. What can such monsterity
    > (in my, beginners eyes) be useful for? I'm sure there's a
    > point to that and it'd be easier to live if i knew.
    > ...


    How exactly do you think it could look if it were "a part of the language"? In
    this case we use include guards built from preprocessor directives and
    preprocessor is a part of the language already. How much more "part of the
    language" do you imply it could've been made?

    Note that fully automatic unconditional protection from repetitive inclusion of
    the same header file into the same translation unit (if that's what you meant)
    is not an acceptable solution, since in some cases we might actually want to
    perform such a repetitive inclusion.

    One can also mention that it was once a popular alternative approach to handling
    include dependencies, where interface-level headers were not supposed to be
    included into other headers at all, meaning that in your example instead of
    including 'A.h' into 'B.h' and 'C.h' you'd have to remember to include it into
    'main.cpp'

    #include "A.h"
    #include "B.h"
    #include "C.h"

    Theoretically, this approach might lead to a better translation performance. It
    doesn't appear to be a significant issue today, but it definitely was a much
    bigger deal, say, a decade ago. Maybe that's a part of the answer to your "why"
    question: at that time it was assumed that it is better to flag the
    multiple-inclusion problem than to quietly handle it automatically or to support
    (and thus encourage) it in any way by some "part of the language" feature.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Mar 19, 2007
    #6
  7. Marcus Kwok

    Greg Herlihy Guest

    On 3/19/07 3:53 PM, in article , "Andrey
    Tarasevich" <> wrote:

    > The Cool Giraffe wrote:
    >> ...
    >> My, my, my... I get the point and i'd like to thank you for the
    >> answer. However, i can't stop wondering why such utility isn't
    >> by default a part of the language. What can such monsterity
    >> (in my, beginners eyes) be useful for? I'm sure there's a
    >> point to that and it'd be easier to live if i knew.
    >> ...

    >
    > How exactly do you think it could look if it were "a part of the language"? In
    > this case we use include guards built from preprocessor directives and
    > preprocessor is a part of the language already. How much more "part of the
    > language" do you imply it could've been made?


    Quite a bit - at least enough to eliminate the current kludge (the one
    cobbled together from a preprocessor macro and an #ifdef) that a C++
    programmers often must resort to - given the lack of a more reasonable
    facility in C++ to prevent a translation unit from including the same header
    file more than once.

    A built-in header guard would have to be concise, accurate and clear (in
    other words, everything that the current macro include guard is not). A
    simple preprocessor directive would probably do the trick:

    #once

    In fact, several C++ compilers (Metrowerks, Visual C++, gcc) offer a
    "#pragma once" which has the same semantics envisioned for the #once
    directive above. So adopting #once would formalize and standardize an
    existing, proven solution. The #once directive would for that reason carry
    little technical risk - yet make C++ sources more portable, and their
    dependencies, easier to manage.

    > Note that fully automatic unconditional protection from repetitive inclusion
    > of
    > the same header file into the same translation unit (if that's what you meant)
    > is not an acceptable solution, since in some cases we might actually want to
    > perform such a repetitive inclusion.


    The idea would be to add #once to those header files that should be included
    once - and not add #once to any header file that should be included more
    than once by a single translation unit. I imagine that most C++ programmers
    will be able to remember this straightforward guideline.

    > One can also mention that it was once a popular alternative approach to
    > handling
    > include dependencies, where interface-level headers were not supposed to be
    > included into other headers at all, meaning that in your example instead of
    > including 'A.h' into 'B.h' and 'C.h' you'd have to remember to include it into
    > 'main.cpp'
    >
    > #include "A.h"
    > #include "B.h"
    > #include "C.h"
    >
    > Theoretically, this approach might lead to a better translation performance.
    > It
    > doesn't appear to be a significant issue today, but it definitely was a much
    > bigger deal, say, a decade ago.


    Since C++ templates have moved code into header files, the old maxim that
    headers should not include other header files - is no longer a practical
    goal.

    > Maybe that's a part of the answer to your
    > "why"
    > question: at that time it was assumed that it is better to flag the
    > multiple-inclusion problem than to quietly handle it automatically or to
    > support
    > (and thus encourage) it in any way by some "part of the language" feature.


    If the compiler is able to ensure that a header file is included only once
    for a translation unit, what is the benefit of forcing the programmer to
    accomplish the same result - but have to do so by laboriously tinkering with
    complex include dependencies in a trial-and-error search for an #include
    order that works?

    After all, compilers should make programmers' jobs easier, not the other way
    around (now that a programmer's time typically costs much more than the
    computer's). And header guards are a good example where C++ could do more
    for the programmer. I would estimate that about 99% of C++ headers that I
    have seen contain header guards of one sort or another. And to have so
    widespread a need be met by embarrassing preprocessor hacks or compiler
    specific pragmas - is no excuse for C++'s continued benign neglect of this
    issue.

    Greg
    Greg Herlihy, Mar 20, 2007
    #7
  8. Marcus Kwok

    Jim Langston Guest

    "The Cool Giraffe" <> wrote in message
    news:...
    > Marcus Kwok wrote/skrev/kaita/popisal/schreibt :
    >> The Cool Giraffe <> wrote:

    >
    >>> I have the following:
    >>>
    >>> //A.h
    >>> class A {};
    >>>
    >>> //B.h
    >>> #include "A.h"
    >>> class B : A {};
    >>>
    >>>
    >>> //C.h
    >>> #include "A.h"
    >>> class C : A {};
    >>>
    >>> In my "main.cpp" I go:
    >>>
    >>> #include "B.h"
    >>> #include "C.h"
    >>>
    >>> and bad things happen. How do I aviod it?
    >>>
    >>> I have heard something about IFNDEF but I don??t really
    >>> feel competent to use it. Trial and error would be very
    >>> time consuming.

    >>
    >> The way ifndef works is, "if the following symbol is not defined, then
    >> do whatever". So,
    >>
    >> //A.h
    >> #ifndef A_H
    >> #define A_H
    >>
    >> class A {};
    >>
    >> #endif
    >>
    >>
    >> //B.h
    >> #ifndef B_H
    >> #define B_H
    >>
    >> #include "A.h"
    >> class B : A {};
    >>
    >> #endif
    >>
    >> and similarly for C.h. Therefore, the first time it tries to #include
    >> A.h, the A_H macro is not defined yet, so the first thing it does is
    >> to #define A_H. When A.h is included again in the same translation
    >> unit (your main.cpp), A_H is already defined, so it skips down to the
    >> #endif, jumping over the definition of class A.

    >
    >
    > My, my, my... I get the point and i'd like to thank you for the
    > answer. However, i can't stop wondering why such utility isn't
    > by default a part of the language. What can such monsterity
    > (in my, beginners eyes) be useful for? I'm sure there's a
    > point to that and it'd be easier to live if i knew.


    They are called "include guards". Microsoft in Visual C++ has a pragma that
    does the same thing
    #pragma once

    Personally, I use include guards even though I'm using code that is specific
    for a windows machine (DirectX). Once you're used to them, you instantly
    recognize them in a header file and they become second nature. They are
    really not any more hideous than any other programming.
    Jim Langston, Mar 20, 2007
    #8
    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. cyril
    Replies:
    2
    Views:
    3,857
    cyril
    Aug 25, 2004
  2. E11
    Replies:
    1
    Views:
    4,736
    Thomas Weidenfeller
    Oct 12, 2005
  3. christopher diggins
    Replies:
    16
    Views:
    745
    Pete Becker
    May 4, 2005
  4. Joseph Turian
    Replies:
    5
    Views:
    585
  5. syang8
    Replies:
    3
    Views:
    251
    ralph
    Mar 2, 2011
Loading...

Share This Page