novice question

[John Smith]

I'm looking at some codes I wrote five years ago when taking a C++
course. Having not touched C++ since, I have forgotten most of it.
Now I can't even comprehend my own codes.

I have a question:

What does these two lines in the attached header file do? I
vaguely remember there is something special about the underscores.

#ifndef __RECORD__
#define __RECORD__

///////////////////////////// Record.h
////////////////////////////////////
// Declare a Record struct to be used in file.h
////////////////////////////////////////////////////////////////////////////
#include "utildll.h"
////////////////////////////////////////////////////////////////////////////
//
// Record struct - contains 4 fields: Name, SSN, Birthdate, State
//
////////////////////////////////////////////////////////////////////////////
#ifndef __RECORD__
#define __RECORD__

struct Record
{
char cName [21],
cSSN [12],
cBirthdate [9],
cState [3];

}; // end of Record structure

#endif

[Kai-Uwe Bux]

John Smith wrote:

I'm looking at some codes I wrote five years ago when taking a C++
course. Having not touched C++ since, I have forgotten most of it.
Now I can't even comprehend my own codes.

I have a question:

What does these two lines in the attached header file do? I
vaguely remember there is something special about the underscores.

#ifndef __RECORD__
#define __RECORD__

a) these two lines are inclusion guards. Everything up to the matching
#endif is included only once.

b) double underscores in identifiers are reserved for the compiler and the
standard library that comes with it. You must not use those in macros of
your own.
Best

Kai-Uwe Bux

[Alf P. Steinbach]

* John Smith:

What does these two lines in the attached header file do?

#ifndef __RECORD__
#define __RECORD__
Those are preprocessor directives. Combined, they ensure that the text in
this file is only included once in each compilation unit. #ifndef tells the
preprocessor to pass on subsequent text to the compiler proper only if the
specified symbol isn't yet defined (this effect lasts until the corresponding
#endif), and #define defines the symbol so that next time around, if this file
is included again somewhere later in this compilation unit, the text is
guaranteed to be ignored, not passed on to the compiler proper.

I vaguely remember there is something special about the underscores.

Yes, names with two underscores are reserved for the implementation. So that
name is a bad one. It may happen to be defined by some standard header.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[David White]

John Smith wrote:

I'm looking at some codes I wrote five years ago when taking a C++
course. Having not touched C++ since, I have forgotten most of it.
Now I can't even comprehend my own codes.

I have a question:

What does these two lines in the attached header file do?
They prevent multiple inclusions of the file, because only the first time
through is __RECORD__ not defined. The #ifndef tests whether it's not
defined, and the #define defines it so the test fails if the file is
included again.
I
vaguely remember there is something special about the underscores.
Yes, you aren't supposed to use leading underscores in names. They are
reserved for the compiler and its supplied libraries' own names.

#ifndef __RECORD__
#define __RECORD__

///////////////////////////// Record.h
////////////////////////////////////
// Declare a Record struct to be used in file.h
//////////////////////////////////////////////////////////////////////////// #include "utildll.h"
//////////////////////////////////////////////////////////////////////////// //
// Record struct - contains 4 fields: Name, SSN, Birthdate, State
//
//////////////////////////////////////////////////////////////////////////// #ifndef __RECORD__
#define __RECORD__
Normally these would be at the very top (without the leading underscores).
Otherwise you might be unnecessarily, or wrongly, including anything that's
above them more than once (in this case the #include "utildll.h" ).

struct Record
{
char cName [21],
cSSN [12],
cBirthdate [9],
cState [3];

}; // end of Record structure

#endif

DW

[Hemanth]

John Smith wrote:

I'm looking at some codes I wrote five years ago when taking a C++
course. Having not touched C++ since, I have forgotten most of it.
Now I can't even comprehend my own codes.

I have a question:

What does these two lines in the attached header file do? I
vaguely remember there is something special about the underscores.

#ifndef __RECORD__
#define __RECORD__

#endif

.........The #ifndef directive is mainly used to prevent multiple
definitions in a header file. For eg. consider a header file (with a
function defined in it) included in two other header files or two
source files. This will lead to multiple inclusions of same code (as
seen by compiler).

To avoid this, we use above directives....f or the first inclusion the
#ifndef returns true but for second inclusion the #ifndef returns
false.

AFAIK, there is nothing special about underscores, they are used only
to make sure the name used is unique. You can also try MYRECORD.
HTH,
Hemanth

[Kev]

Kai-Uwe Bux <jk********@gmx .net> wrote in
news:di******** **@murdoch.acc. Virginia.EDU:

b) double underscores in identifiers are reserved for the compiler and
the standard library that comes with it. You must not use those in
macros of your own.

I didnt know this. I always had the underscores because thats what I
generally saw often. Usually just the name of the file... minus the dot.
What kind of problem could this potentially cause?

[John Harrison]

Kev wrote:

Kai-Uwe Bux <jk********@gmx .net> wrote in
news:di******** **@murdoch.acc. Virginia.EDU:

b) double underscores in identifiers are reserved for the compiler and
the standard library that comes with it. You must not use those in
macros of your own.

I didnt know this. I always had the underscores because thats what I
generally saw often. Usually just the name of the file... minus the dot.
What kind of problem could this potentially cause?

Double underscores are reserved for the compiler so it can define it's
own macros. If the compiler had defined a macro __RECORD__ that would
interfere with the macro you had defined yourself.

Unfortunately there is a lot of bad C++ code around and a lot of people
copying code. It's better to understand C++ that just copy it, this is a
good place for gaining understanding.

John

[David White]

"Kai-Uwe Bux" <jk********@gmx .net> wrote in message
news:di******** **@murdoch.acc. Virginia.EDU...

b) double underscores in identifiers are reserved for the compiler and the
standard library that comes with it. You must not use those in macros of
your own.

As I understand the standard, a single underscore in the OP's case would
also be out:
17.4.3.1.2
1 Certain sets of names and function signatures are always reserved to the
implementation:
- Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.

DW

[Kev]

John Harrison <jo************ *@hotmail.com> wrote in news:2o41f.1070 2
$h******@newsfe 2-gui.ntli.net:

Unfortunately there is a lot of bad C++ code around and a lot of people
copying code. It's better to understand C++ that just copy it, this is a
good place for gaining understanding.

True. But then we all learn by seeing what others have done. At least in
the beginning. Great artists are no different until they develop their own
skills. In fact there is a controversial theory, with some controversial
'evidence', that the great masters traced much of their work by using
mirrors and projections which were invented around the same time.
Supposedly xplaining why the proportions in their paintings are so perfect.
But I digress ;o)

I suppose it also explains the other examples I have seen that include very
long strings of random number-letter combinations, and why VC++ always does
it for pregenerated headers. As far I can tell from my limited experience
anyways. I have as of yet had no such problems in my wee little programs.
But I shall change them.

Thnx

[Mike Wahler]

"Kev" <di************ **@pht.zzz> wrote in message
news:Xn******** **************@ 216.168.3.44...

John Harrison <jo************ *@hotmail.com> wrote in news:2o41f.1070 2
$h******@newsfe 2-gui.ntli.net:

Unfortunately there is a lot of bad C++ code around and a lot of people
copying code. It's better to understand C++ that just copy it, this is a
good place for gaining understanding.
True. But then we all learn by seeing what others have done.

But we can be misled if we not sure exactly what it is
that those others have done, and in this case exactly
who has done it. You were most likely looking at what
an implementor did. There are rules in place which govern
what an implementor or a program author can do. Some of
these rules reserve certain forms of tokens for the implementor
so that they can be assured that there are no name clashes
(if the program author also adheres to the rules).

At least in
the beginning. Great artists are no different until they develop their own
skills. In fact there is a controversial theory, with some controversial
'evidence', that the great masters traced much of their work by using
mirrors and projections which were invented around the same time.
Supposedly xplaining why the proportions in their paintings are so
perfect.
But I digress ;o)

I suppose it also explains the other examples I have seen that include
very
long strings of random number-letter combinations, and why VC++ always
does
it for pregenerated headers. As far I can tell from my limited experience
anyways. I have as of yet had no such problems in my wee little programs.
But I shall change them.

Such problems don't tend to occur until a critical time
(such as when the program gets demonstrated or delivered
to clients) :-)

-Mike