facing problem during compilation

J

jacob navia

Guys,

I have put the following two lines in a header file to prevent it
from getting included multiple times.

#ifndef __MY_HDR.H__
#define __MY_HDR.H__

// Some macros here

#endif

However, when I compile the code, I am getting following warnings,
warning: extra token at end of #ifndef directive
warning ISO C requires whitespace after the macro name


Can anyone help me finding the problem ?

thnaks a lot for any help.

You wrote:

__MY_HDR.H__

The point is NOT an identifier, you can't write points into
an identifier. Then, the compiler sees
__MY_HDR . H__
This is NOT a valid #ifndef directive of course.

Solution
Change
__MY_HDR.H__ to:

__MY_HDR_H__

getting rid of the point.
 
J

junky_fellow

Guys,

I have put the following two lines in a header file to prevent it
from getting included multiple times.

#ifndef __MY_HDR.H__
#define __MY_HDR.H__

// Some macros here

#endif

However, when I compile the code, I am getting following warnings,
warning: extra token at end of #ifndef directive
warning ISO C requires whitespace after the macro name


Can anyone help me finding the problem ?

thnaks a lot for any help.
 
J

Joachim Schmitz

Guys,

I have put the following two lines in a header file to prevent it
from getting included multiple times.

#ifndef __MY_HDR.H__
#define __MY_HDR.H__

// Some macros here

#endif

However, when I compile the code, I am getting following warnings,
warning: extra token at end of #ifndef directive
warning ISO C requires whitespace after the macro name


Can anyone help me finding the problem ?
Guess it's complaining about the .
Also you shouldn't be usign macros or identifiers that start with an _, they
are resoved for the implementation, so try MY_HDR_H or MY_HDR_H_ instead

Bye, Jojo
 
M

Martien verbruggen

Guys,

I have put the following two lines in a header file to prevent it
from getting included multiple times.

#ifndef __MY_HDR.H__
#define __MY_HDR.H__

You can't use a full stop in a preprocessor macro identifier (or any
other identifier). You can use letters (from the english alphabet),
digits and the underscore, and the first character can't be a digit.

You also shouldn't start then with an underscore and follow that with
another underscore or an uppercase letter, as all of those identifiers
are reserved, and not for use by the programmer.

Use something like:

#ifndef MY_HDR_H
#define MY_HDR_H

Martien
 
K

Keith Thompson

Martien verbruggen said:
You can't use a full stop in a preprocessor macro identifier (or any
other identifier). You can use letters (from the english alphabet),
digits and the underscore, and the first character can't be a digit.

You also shouldn't start then with an underscore and follow that with
another underscore or an uppercase letter, as all of those identifiers
are reserved, and not for use by the programmer.

Use something like:

#ifndef MY_HDR_H
#define MY_HDR_H

Using this pattern presents a risk of stepping on the implementation's
reserved namespace if your header name happens to start with 'e',
since identifiers starting with an upper-case 'E' followed by another
upper-case letter are reserved as errno macros.

Even though it hurts readability a bit, consider using:

#ifndef H_MY_HDR
#define H_MY_HDR
...
#endif
 
C

CBFalconer

jacob said:
You wrote:

__MY_HDR.H__

The point is NOT an identifier, you can't write points into
an identifier. Then, the compiler sees
__MY_HDR . H__
This is NOT a valid #ifndef directive of course.

Solution: Change
__MY_HDR.H__ to:

__MY_HDR_H__

getting rid of the point.

This is true, but the identifier is still illegal. Get rid of the
leading "__" in the name. Such names are reserved for the
implementation. I use a leading H_, thus avoiding every getting
the illegal E* names (also reserved).
 
J

jacob navia

CBFalconer said:
This is true, but the identifier is still illegal. Get rid of the
leading "__" in the name. Such names are reserved for the
implementation. I use a leading H_, thus avoiding every getting
the illegal E* names (also reserved).

It is true that those names are reserved, but with
your schema you can conflict with some H_* name in the program...

Name conflicts are impossible to avoid.

jacob
 
R

Richard Tobin

This is true, but the identifier is still illegal. Get rid of the
leading "__" in the name. Such names are reserved for the
implementation. I use a leading H_, thus avoiding every getting
the illegal E* names (also reserved).

The standard authors may have reserved to the implemention macro names
of the form E[A-Z0-9]_H, but I'll be happy to avoid any implementation
that uses them.

-- Richard
 
R

Richard Tobin

Keith Thompson said:
Using this pattern presents a risk of stepping on the implementation's
reserved namespace if your header name happens to start with 'e',
since identifiers starting with an upper-case 'E' followed by another
upper-case letter are reserved as errno macros.

But any library you use may happen to define a macro that conflicts
with a name you choose. The chance of an implementation defining an
errno ending _H is no greater - and probably much smaller, because it
would be Obviously Stupid.

-- Richard
 
J

jacob navia

Richard said:
But any library you use may happen to define a macro that conflicts
with a name you choose. The chance of an implementation defining an
errno ending _H is no greater - and probably much smaller, because it
would be Obviously Stupid.

-- Richard

The problem has no solution

besides...

#pragma once

But we have discussed this several times. I think
#pragma once
is a good solution and my compiler system implements it.

With this pragma, there is NO NEED to figure out a name.

jacob
 
K

Keith Thompson

jacob navia said:
The problem has no solution

besides...

#pragma once

But we have discussed this several times. I think
#pragma once
is a good solution and my compiler system implements it.

With this pragma, there is NO NEED to figure out a name.

But of course your code loses portability to implementations that
don't support #pragma once. I wouldn't mind if it had been
standardized, but it wasn't. (And determining whether two names refer
to the same file can be non-trivial on some systems; the #ifndef
technique lets the programmer assign a unique name to each file.)

In any case, C has a fundamental problem with name collisions. The
usual workaround is to apply a common prefix to each visible
identifier, but there's no real guarantee that two organizations won't
pick the same prefix. Even C++-style namespaces and other similar
mechanisms don't completely solve the problem, unless you can set up
and enforce a central registry of prefixes, or namespace names, or
whatever.

#pragma once is a nice feature, and it's useful for reasons other than
avoiding name collisions, but it only addresses one small piece of the
general name collision problem.

In practice, programmers *usually* can manage to pick unique names
with only occasional problems. There are no perfect solutions, but
there are plenty of imperfect ones.
 
J

jacob navia

Keith said:
In practice, programmers *usually* can manage to pick unique names
with only occasional problems. There are no perfect solutions, but
there are plenty of imperfect ones.

Yes, there are no solutions that are perfect in all cases for this
problem.

One advantage of the
#ifndef
#define
....
#endif
method, is that you can "turn off" an included
file!!

Imagine that foo.c includes keith.h and
that includes chris.h

If you want to include keith.h without including
chris.h for whatever reason you call the compiler
with

compiler -D__chris_h__ foo.c

and you have that file completely commented out!
 
C

CBFalconer

Richard said:
CBFalconer said:
This is true, but the identifier is still illegal. Get rid of the
leading "__" in the name. Such names are reserved for the
implementation. I use a leading H_, thus avoiding every getting
the illegal E* names (also reserved).

The standard authors may have reserved to the implemention macro
names of the form E[A-Z0-9]_H, but I'll be happy to avoid any
implementation that uses them.

Then you will have to avoid almost all implementations of a C
system. Take a look at the E(rror) id macros.
 
K

Keith Thompson

CBFalconer said:
Richard said:
CBFalconer said:
This is true, but the identifier is still illegal. Get rid of the
leading "__" in the name. Such names are reserved for the
implementation. I use a leading H_, thus avoiding every getting
the illegal E* names (also reserved).

The standard authors may have reserved to the implemention macro
names of the form E[A-Z0-9]_H, but I'll be happy to avoid any
implementation that uses them.

Then you will have to avoid almost all implementations of a C
system. Take a look at the E(rror) id macros.

I think he's well aware of that.

Yes, it's true that all identifiers starting with an uppercase 'E'
followed by either a digit or another uppercase letter are reserved.
But using such an identifier that doesn't happen to be one that's used
by the current implementation is very likely to be harmless, and it's
extremely unlikely that any implementation actually uses an identifier
starting with "E" and ending with "_H".

I'd still prefer to stick to H_NAME, for include guard macros, but its
true that using NAME_H is very unlikely *in practice* to cause any
problems.
 
J

jaysome

CBFalconer said:
Richard said:
This is true, but the identifier is still illegal. Get rid of the
leading "__" in the name. Such names are reserved for the
implementation. I use a leading H_, thus avoiding every getting
the illegal E* names (also reserved).

The standard authors may have reserved to the implemention macro
names of the form E[A-Z0-9]_H, but I'll be happy to avoid any
implementation that uses them.

Then you will have to avoid almost all implementations of a C
system. Take a look at the E(rror) id macros.

I think he's well aware of that.

Yes, it's true that all identifiers starting with an uppercase 'E'
followed by either a digit or another uppercase letter are reserved.
But using such an identifier that doesn't happen to be one that's used
by the current implementation is very likely to be harmless, and it's
extremely unlikely that any implementation actually uses an identifier
starting with "E" and ending with "_H".

Let alone any identifier that begins with "E" and contains an
underscore, let alone one that contains *multiple* underscores. For
example, the identifier used here:

/* entropy.h */
#ifndef ENTROPY_H_INCLUDED__

has 0 probability of being used by an implementation, IMHO.
I'd still prefer to stick to H_NAME, for include guard macros, but its
true that using NAME_H is very unlikely *in practice* to cause any
problems.

Just like an identifier that matches the regular expression:
..+.*_H_INCLUDED__

is very unlikely *in practice* to cause any problems.
 
R

Richard Tobin

The standard authors may have reserved to the implemention macro
names of the form E[A-Z0-9]_H, but I'll be happy to avoid any
implementation that uses them.
[/QUOTE]
Then you will have to avoid almost all implementations of a C
system. Take a look at the E(rror) id macros.

I did, and none of them are of that form.

-- Richard
 
A

Army1987

Richard said:
The standard authors may have reserved to the implemention macro
names of the form E[A-Z0-9]_H, but I'll be happy to avoid any
implementation that uses them.
Then you will have to avoid almost all implementations of a C
system. Take a look at the E(rror) id macros.
On my implementation of a C system, none of them ends with _H.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top