C is too old? opinions?

[jacob navia]

I use PROJECTNAME_PATHNAME

with PROJECTNAME is the name of the project in uppercase.
and PATHNAME is the name of the header file including the relative path in
the project hierarchy, uppercased with all non alphanumeric characters
replaced with underscores.

lib/compress/huffman.h in project zipklone would be protected by

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once

Chqrlie?

 

[Joachim Schmitz]

[...]
I like the trailing underscore, because I think that the
header guards should have a unique format that is not
likely to be accidentally written in a non header guard macro.

When I had a file named sort.h, I tried a header guard H_SORT,
but there was a problem because the program also had macros like
B_SORT
I_SORT
S_SORT
Q_SORT
and of course: H_SORT

I kept my H_SORT macro for heapsort,
and changed some other things instead.

At this current time, I'm using H_filename_H.
Presumably the "filename" portion consists only of letters, digits,
and underscores (i.e., you strip the trailing ".h").

I use PROJECTNAME_PATHNAME

with PROJECTNAME is the name of the project in uppercase.
and PATHNAME is the name of the header file including the relative path
in the project hierarchy, uppercased with all non alphanumeric characters
replaced with underscores.

lib/compress/huffman.h in project zipklone would be protected by

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once

Because it's not supported on every compiler, unfortunatly.
It's a common extension, but not in the Standard.

Bye, Jojo

 

[Joachim Schmitz]

I like the trailing underscore, because I think that the
header guards should have a unique format that is not
likely to be accidentally written in a non header guard macro.

On a platform that I frequently work with, quite a few API calls have
trailing underscores and are spelled in all-caps.

Bye, Jojo

 

[Ben Pfaff]

Why not

#pragma once

Because it doesn't work on every compiler?

 

[Tor Rustad]

Charlie Gordon wrote:
[...]

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once

Chapter and verse please.

 

[Richard]

Charlie Gordon wrote:
[...]

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once

Chapter and verse please.

The book of common sense when using well known compilers, page 1.

It is an answer to problems people might have in C. And good advice
too. If your C *must* be 100% standard compatible amongst ALL compilers
then clearly not. But for a LOT of people using many compilers very
useful to know.

Good advice Jacob.

 

[jacob navia]

Charlie Gordon wrote: [...]

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once

Chapter and verse please.

The book of common sense when using well known compilers, page 1.

It is an answer to problems people might have in C. And good advice
too. If your C *must* be 100% standard compatible amongst ALL compilers
then clearly not. But for a LOT of people using many compilers very
useful to know.

Good advice Jacob.

It is supported by
1) MSVC (windows)
2) Intel compiler
2) Comeau C/C++ (Unix and windows)
3) Digital Mars C/C++ (Unix+Windows I think)
4) gcc (versions later than 3.4) (Unix)
5) lcc-win32 (Windows)
6) Delorie C/C++ (MSDOS)
7) MIPS PRO C/C++ (SGI)
8) Code Warrior (MacIntosh version)
9) Digital C++ (Unix)
10) MPW C compiler (Macintosh)
11) The Watcom compiler

 

[Richard Heathfield]

Tor Rustad said:

Charlie Gordon wrote:
[...]

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once

Chapter and verse please.

Alas, chapter and verse will not be forthcoming, because the C Standard
doesn't mention '#pragma once' specifically. It does, however, have this
to say about pragmas in general:

1 A preprocessing directive of the form
# pragma pp-tokensopt new-line
where the preprocessing token STDC does not immediately follow pragma in
the directive (prior to any macro replacement)146) causes the
implementation to behave in an implementation-defined manner. The behavior
might cause translation to fail or cause the translator or the resulting
program to behave in a non-conforming manner. Any such pragma that is not
recognized by the implementation is ignored.

So the advice here is to use a pragma that might be ignored or might do
something arbitrary and unexpected - and incredibly bad advice it is.
Anyone capable of implementing a C compiler *must* be well aware of this.
Draw your own conclusions.

 

[Keith Thompson]

jacob navia wrote: [...]
Why not

#pragma once
Chapter and verse please.

[...]

It is supported by
1) MSVC (windows)
2) Intel compiler
2) Comeau C/C++ (Unix and windows)
3) Digital Mars C/C++ (Unix+Windows I think)
4) gcc (versions later than 3.4) (Unix)
5) lcc-win32 (Windows)
6) Delorie C/C++ (MSDOS)
7) MIPS PRO C/C++ (SGI)
8) Code Warrior (MacIntosh version)
9) Digital C++ (Unix)
10) MPW C compiler (Macintosh)
11) The Watcom compiler

The very fact that you need to list the implementations that support
it emphasizes the fact that it's non-standard.

If you happen to have the luxury of assuming that your code will be
compiled only by compilers that support '#pragma once', then it might
make sense to use it. If you intend your code to be as portable as
possible, if you don't *know* what compilers may be used to compile
your code, you need to use the old '#ifndef' trick.

For that matter, how sure can you be that all 11 of those compilers,
and all other compilers that happen to implement '#pragma once', do so
with exactly the same syntax and semantics? And do all of those
compilers accept '#pragma once' when invoked in either C90 or C99
conforming mode? If not, it could be used only at the cost of losing
checks for other non-standard constructs, even on compilers that
support it.

On some systems, there are corner cases that could cause problems.
Presumably when '#pragma once' is encountered, it causes the compiler
to remember the name of the current file and to ignore any future
#include directives for that file. But what happens if the same file
is referred to by two different names? There are a number of ways
this could happen on Unix-like systems, for example. Such problems
probably aren't too difficult to avoid, but I'd want to have a precise
definition of the feature before I'd feel comfortable using it.

(Incidentally, I just checked the gcc documentation, to see if I could
find *some* specification for '#pragma once'. It doesn't mention it
at all.)

If you want to suggest '#pragma once', that's ok with me, but *please*
don't do so without mentioning that it's non-standard. It's a nice
feature, and I wouldn't mind having it in the standard (though
defining it precisely might be difficult), but there is a cost to
using it.

 

[Richard]

If you want to suggest '#pragma once', that's ok with me, but *please*
don't do so without mentioning that it's non-standard. It's a nice
feature, and I wouldn't mind having it in the standard (though
defining it precisely might be difficult), but there is a cost to
using it.

This is a sensible reply.

There is a chance that the OP was interested in how best to achieve
something. "Best" does not, in his case, necessarily mean using the
standard. Nothing wrong with sharing a little bit of experience with the
usual caveats.

 

[Flash Gordon]

jacob navia wrote, On 26/09/07 18:58:

jacob navia wrote:
Charlie Gordon wrote:
[...]

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once
Chapter and verse please.

The book of common sense when using well known compilers, page 1.

It is an answer to problems people might have in C. And good advice
too. If your C *must* be 100% standard compatible amongst ALL compilers
then clearly not. But for a LOT of people using many compilers very
useful to know.

Good advice Jacob.

It is supported by
1) MSVC (windows)

11) The Watcom compiler

Alternatively, you could use the normal method that is supported by,
hold on whilst I count...




Sorry, I lost count whilst counting all of the conforming compilers.

So on the one hand we have a method supported by at least 11 compilers
and used by some people. On the other hand we have the method most
people use that is supported by ALL conforming compilers and probably
most non-conforming compilers as well.

 

[Richard]

jacob navia wrote, On 26/09/07 18:58:

jacob navia wrote:
Charlie Gordon wrote:
[...]

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once
Chapter and verse please.

The book of common sense when using well known compilers, page 1.

It is an answer to problems people might have in C. And good advice
too. If your C *must* be 100% standard compatible amongst ALL compilers
then clearly not. But for a LOT of people using many compilers very
useful to know.

Good advice Jacob.

It is supported by
1) MSVC (windows)

11) The Watcom compiler

Alternatively, you could use the normal method that is supported by,
hold on whilst I count...

Sorry, I lost count whilst counting all of the conforming compilers.

So on the one hand we have a method supported by at least 11 compilers
and used by some people. On the other hand we have the method most
people use that is supported by ALL conforming compilers and probably
most non-conforming compilers as well.

If you can't see how using "#pragma once" is superior in terms of ease
of use and less "intrusion" in "real" code which will never be targeted
at all these platforms that exist in the heavens then god help you.

 

[Flash Gordon]

Richard wrote, On 26/09/07 21:16:

If you can't see how using "#pragma once" is superior in terms of ease
of use and less "intrusion" in "real" code which will never be targeted
at all these platforms that exist in the heavens then god help you.

If it was standardised then I would use it. However, if you really find
writing three simple lines too hard then God help you.

There are good reasons for writing non-portable code and bad reasons. I
would put replacing three simple lines per header with one simple lines
in the bad camp, especially since you have to understand the method
anyway if you want to be able to read most C code.

 

[pete]

I use PROJECTNAME_PATHNAME

with PROJECTNAME is the name of the project in uppercase.
and PATHNAME is the name of the header file including the relative path in
the project hierarchy, uppercased with all non alphanumeric characters
replaced with underscores.

lib/compress/huffman.h in project zipklone would be protected by

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

It is not unreasonable.
I will consider it.
Thank you.

 

[jacob navia]

If it was standardised then I would use it. However, if you really find
writing three simple lines too hard then God help you.

There are good reasons for writing non-portable code and bad reasons. I
would put replacing three simple lines per header with one simple lines
in the bad camp, especially since you have to understand the method
anyway if you want to be able to read most C code.

You missed apparently the whole *previous* discussion about the name
conflict potential of the different schemas that the
#ifndef NAME /endif schema needs.

The principal reason for #pragma once is it that it doesn't need
a name.

But now the arguments are known, let's just agree that we disagree.

 

[Tor Rustad]

Charlie Gordon wrote: [...]

#ifdef ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
#define ZIPCLONE_LIB_COMPRESS_HUFFMAN_H
...
#endif

The scheme leaves little room for collisions and can be automated too.

Why not

#pragma once

Chapter and verse please.

The book of common sense when using well known compilers, page 1.

Since when did c.l.c degenerate into such lack of common sense? *shocked*


I have never been hit by name collision problems by #ifdef & #define's
in header files, a simple _H suffix after filename works well in practice.


The theoretical issue that implementations has grabbed the whole
E[0-9A-Z]+ name space, is rather a problem when defining your own error
codes.

Good advice Jacob.

Wrong, it was bad advice. It solves no real problem, and breaks
portability. At least 50% of the C compilers I regularly use, was not on
that list.

 

[Keith Thompson]

You missed apparently the whole *previous* discussion about the name
conflict potential of the different schemas that the
#ifndef NAME /endif schema needs.

The principal reason for #pragma once is it that it doesn't need
a name.

And the principal reason *not* to use it is that it's non-standard and
potentially non-portable.

But now the arguments are known, let's just agree that we disagree.

If you refuse to acknowledge that it's non-standard and potentially
non-portable, this is not just a difference of opinion. There's a
real cost for using it, and you ignore that fact.

 

[Philip Potter]

This is a sensible reply.

There is a chance that the OP was interested in how best to achieve
something. "Best" does not, in his case, necessarily mean using the
standard. Nothing wrong with sharing a little bit of experience with the
usual caveats.

I don't see what benefit #pragma once brings, given its nonstandard cost. Even
if I knew that I'd be using only implementations which supported it, I'd
probably still use the #ifndef trick.

Though you are of course correct that some nonstandard features are both useful
and desirable. This is just not one of them.

 

[CBFalconer]

.... snip ...

Why not

#pragma once

Not portable.

 

[CBFalconer]

It is supported by

.... snip specific list ...

It's terrible advice. Why use something that works on a few
specific systems when you can have a system that works all the time
on all systems?