Multiple Inclusion Guards Work in MSVC++ .NET...right?

[Fritz Foetzl]

I'm flummoxed. I'm a veteran C++ programmer from the Unix/Linux camp,
trying to learn Visual C++. I'm trying to build a project in which I
need to include one header in a couple of different files, but the
classic multiple inclusion problem is biting me hard. The
#ifndef..#defin e..#endif method doesn't seem to be working, although
all the documentation I've read indicates that it should.

As a small example, I have an empty console project with three files:
globals.h, functions.cpp and driver.cpp. They look like this:

// ----------------------------------------------------
// globals.h
#ifndef _GLOBALS_
#define _GLOBALS_

const char *msg = "Wiggety wack";

#endif
// EOF

// ----------------------------------------------------
// functions.cpp
#include <iostream>
using namespace std;

#include "globals.h"

void getWiggety ()
{
cout << msg << endl;
}
// EOF

// ----------------------------------------------------
// driver.cpp
#include <iostream>
using namespace std;

#include "globals.h"

extern void getWiggety (void);

int main (void)
{
cout << msg << endl;
getWiggety ();
return 0;
}
// EOF

This won't link, because msg is declared twice, in spite my
#ifndef..#defin e..#endif in globals.h. I've gone and looked at
<iostream>, and it's protected against multiple inclusion the same way
as I'm doing it. I'm also including it in two places but...the linker
doesn't complain about std::cout et. al.

WTFO?

ff

[Jonathan Turkanis]

"Fritz Foetzl" <fr**********@h otmail.com> wrote in message
news:d2******** *************** ***@posting.goo gle.com...

I'm flummoxed. I'm a veteran C++ programmer from the Unix/Linux camp, trying to learn Visual C++. I'm trying to build a project in which I
need to include one header in a couple of different files, but the
classic multiple inclusion problem is biting me hard. The
#ifndef..#defin e..#endif method doesn't seem to be working, although
all the documentation I've read indicates that it should.

As a small example, I have an empty console project with three files: globals.h, functions.cpp and driver.cpp. They look like this:

// ----------------------------------------------------
// globals.h
#ifndef _GLOBALS_
#define _GLOBALS_

const char *msg = "Wiggety wack";

#endif
// EOF

// ----------------------------------------------------
// functions.cpp
#include <iostream>
using namespace std;

#include "globals.h"

void getWiggety ()
{
cout << msg << endl;
}
// EOF

// ----------------------------------------------------
// driver.cpp
#include <iostream>
using namespace std;

#include "globals.h"

extern void getWiggety (void);

int main (void)
{
cout << msg << endl;
getWiggety ();
return 0;
}
// EOF

I think your problem has nothing to do with include guards. The header
"globals.h" is properly included twice, once when each of the files
"driver.cpp " and "functions. cpp" is compiled. The problem is that msg
is being defined twice in the same program, violating the ODR.

You should probably decalre it extern and define it in "global.cpp ",
or use an inline function instead

inline msg()
{
static const char* s = "Wiggety wack";
return s;
}

Jonathan

[Kevin Goodsell]

Fritz Foetzl wrote:

I'm flummoxed. I'm a veteran C++ programmer from the Unix/Linux camp,
trying to learn Visual C++. I'm trying to build a project in which I
need to include one header in a couple of different files, but the
classic multiple inclusion problem is biting me hard. The
#ifndef..#defin e..#endif method doesn't seem to be working, although
all the documentation I've read indicates that it should.

As a small example, I have an empty console project with three files:
globals.h, functions.cpp and driver.cpp. They look like this:

// ----------------------------------------------------
// globals.h
#ifndef _GLOBALS_
#define _GLOBALS_

You need a new idiom for include guard names. Identifiers beginning with
an underscore followed by an upper case letter or another underscore are
reserved for the implementation' s use for any purpose. Unless you are
sure you know better, avoid identifiers that begin with an underscore.

This is not your problem, however. Nor is it multiple inclusion. Include
guards protect against the same thing appearing multiple times in a
single translation unit, but not against the same thing appearing in two
different translation units. For example, if I have a main() function in
a.cpp and I also have a main() function in b.cpp, my program won't link.
This is basically what you are doing - you have 'msg' appearing in both
..cpp files, because each has it's own #included copy of globals.h.

The proper way to do this is to only declare 'msg' in the header (with
'extern', and no initialization) and then have its definition (along
with the initialization) in a .cpp file somewhere.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[John Carson]

"Kevin Goodsell" <us************ *********@never box.com> wrote in
message news:DR******** *********@newsr ead2.news.pas.e arthlink.net

This is not your problem, however. Nor is it multiple inclusion.
Include guards protect against the same thing appearing multiple
times in a single translation unit, but not against the same thing
appearing in two different translation units. For example, if I have
a main() function in a.cpp and I also have a main() function in
b.cpp, my program won't link. This is basically what you are doing -
you have 'msg' appearing in both .cpp files, because each has it's
own #included copy of globals.h.

The proper way to do this is to only declare 'msg' in the header (with
'extern', and no initialization) and then have its definition (along
with the initialization) in a .cpp file somewhere.

I agree that that is the best way to do it, but I think that the strategy of
the OP should still work. This is because const variables should have
internal linkage by default, i.e.,

const char *msg = "Wiggety wack";

should be equivalent to

static const char *msg = "Wiggety wack";

The latter will certainly build without a problem and so should the former.

--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Jonathan Turkanis]

"John Carson" <do***********@ datafast.net.au > wrote in message:

This is not your problem, however. Nor is it multiple inclusion.
Include guards protect against the same thing appearing multiple
times in a single translation unit, but not against the same thing
appearing in two different translation units. For example, if I have a main() function in a.cpp and I also have a main() function in
b.cpp, my program won't link. This is basically what you are doing - you have 'msg' appearing in both .cpp files, because each has it's
own #included copy of globals.h.

The proper way to do this is to only declare 'msg' in the header (with 'extern', and no initialization) and then have its definition (along with the initialization) in a .cpp file somewhere.
I agree that that is the best way to do it, but I think that the

strategy of the OP should still work. This is because const variables should have internal linkage by default, i.e.,

const char *msg = "Wiggety wack";

should be equivalent to

static const char *msg = "Wiggety wack";

The latter will certainly build without a problem and so should the former.

The former does not build on VC7.1 or GCC 3.2, and I don't see why it
should. 3.5/3 says names explicitly declared const have internal
linkage if they are objects or references; msg is a pointer. Could you
explain why you think msg should have internal linkage?

Regards,
Jonathan

[John Carson]

"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message
news:bu******** ****@ID-216073.news.uni-berlin.de

"John Carson" <do***********@ datafast.net.au > wrote in message:

I agree that that is the best way to do it, but I think that the
strategy of the OP should still work. This is because const
variables should have internal linkage by default, i.e.,

const char *msg = "Wiggety wack";

should be equivalent to

static const char *msg = "Wiggety wack";

The latter will certainly build without a problem and so should the
former.

The former does not build on VC7.1 or GCC 3.2, and I don't see why it
should. 3.5/3 says names explicitly declared const have internal
linkage if they are objects or references; msg is a pointer. Could you
explain why you think msg should have internal linkage?

Regards,
Jonathan

Actually, we are both wrong. A const pointer does have internal linkage, as
I suggested, but

const char *msg = "Wiggety wack";

does not define a const pointer. Rather, it defines a non-const pointer to
const char. To create a const pointer, we need:

const char * const msg = "Wiggety wack";

This compiles on VC++ 7.0.

As for the standard, it says:

"A name having namespace scope (3.3.5) has internal linkage if it is the
name of
— an object, reference, function or function template that is explicitly
declared static or,
— an object or reference that is explicitly declared const and neither
explicitly declared extern nor previously declared to have external linkage;
or ..."

Observe that there is no explicit mention of pointers under the first dashed
point dealing with the use of the static keyword, yet we know that declaring
a pointer static will give it internal linkage. Accordingly, I infer that
pointers are included as "objects" under both dashed points.
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Jonathan Turkanis]

"John Carson" <do***********@ datafast.net.au > wrote in message
news:40******** @usenet.per.par adox.net.au...

"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message

The former does not build on VC7.1 or GCC 3.2, and I don't see why it should. 3.5/3 says names explicitly declared const have internal
linkage if they are objects or references; msg is a pointer. Could you explain why you think msg should have internal linkage?

Regards,
Jonathan

Actually, we are both wrong. A const pointer does have internal

linkage, as I suggested, but

const char *msg = "Wiggety wack";
Your right. Duh!

As for the standard, it says:

"A name having namespace scope (3.3.5) has internal linkage if it is the name of
— an object, reference, function or function template that is explicitly declared static or,
— an object or reference that is explicitly declared const and neither explicitly declared extern nor previously declared to have external linkage; or ..."

Observe that there is no explicit mention of pointers under the first dashed point dealing with the use of the static keyword, yet we know that declaring a pointer static will give it internal linkage. Accordingly, I infer that pointers are included as "objects" under both dashed points.

I don't follow your reasoning here. The passage is talking about
const, not static. I believe objects and pointers are usually treated
separately by the standard.

Jonathan

[Jonathan Turkanis]

"John Carson" <do***********@ datafast.net.au > wrote in message
news:40******** @usenet.per.par adox.net.au...

"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message
"A name having namespace scope (3.3.5) has internal linkage if it is the name of
— an object, reference, function or function template that is explicitly declared static or,
— an object or reference that is explicitly declared const and neither explicitly declared extern nor previously declared to have external linkage; or ..."

I guess the answer comes from 1.8/1.

Jonathan

[John Carson]

"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message
news:bu******** ****@ID-216073.news.uni-berlin.de

"John Carson" <do***********@ datafast.net.au > wrote in message
news:40******** @usenet.per.par adox.net.au...

"A name having namespace scope (3.3.5) has internal linkage if it
is the name of
— an object, reference, function or function template that is
explicitly declared static or,
— an object or reference that is explicitly declared const and
neither explicitly declared extern nor previously declared to have
external linkage; or ..."

I guess the answer comes from 1.8/1.

Jonathan

Yep. "An object is a region of storage."
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[John Carson]

"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message
news:bu******** ****@ID-216073.news.uni-berlin.de

"John Carson" <do***********@ datafast.net.au > wrote in message
news:40******** @usenet.per.par adox.net.au...

"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message

>

The former does not build on VC7.1 or GCC 3.2, and I don't see
why it should. 3.5/3 says names explicitly declared const have
internal linkage if they are objects or references; msg is a
pointer. Could you explain why you think msg should have internal
linkage?

Regards,
Jonathan

Actually, we are both wrong. A const pointer does have internal
linkage, as I suggested, but

const char *msg = "Wiggety wack";

Your right. Duh!

As for the standard, it says:

"A name having namespace scope (3.3.5) has internal linkage if it
is the name of
— an object, reference, function or function template that is
explicitly declared static or,
— an object or reference that is explicitly declared const and
neither explicitly declared extern nor previously declared to have
external linkage; or ..."

Observe that there is no explicit mention of pointers under the
first dashed point dealing with the use of the static keyword, yet
we know that declaring a pointer static will give it internal
linkage. Accordingly, I infer that pointers are included as
"objects" under both dashed points.

I don't follow your reasoning here. The passage is talking about
const, not static. I believe objects and pointers are usually treated
separately by the standard.

Look again. The first dashed point says:

"an object, reference, function or function template that is explicitly
declared static"
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)