By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,929 Members | 1,245 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,929 IT Pros & Developers. It's quick & easy.

Class redefintion problem

P: n/a
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)
Mar 19 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
The Cool Giraffe <gi******@viltersten.comwrote:
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
Mar 19 '07 #2

P: n/a
"The Cool Giraffe" <gi******@viltersten.comwrote 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).

Mar 19 '07 #3

P: n/a
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
Mar 19 '07 #4

P: n/a
Marcus Kwok wrote/skrev/kaita/popisal/schreibt :
The Cool Giraffe <gi******@viltersten.comwrote:
>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)
Mar 19 '07 #5

P: n/a
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
Mar 19 '07 #6

P: n/a
On 3/19/07 3:53 PM, in article 12*************@news.supernews.com, "Andrey
Tarasevich" <an**************@hotmail.comwrote:
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

Mar 20 '07 #7

P: n/a
"The Cool Giraffe" <gi******@viltersten.comwrote in message
news:56*************@mid.individual.net...
Marcus Kwok wrote/skrev/kaita/popisal/schreibt :
>The Cool Giraffe <gi******@viltersten.comwrote:
>>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.
Mar 20 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.