C is too old? opinions?

[Kenny McCormack]

Not portable.

ITYM:

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

--
Useful clc-related links:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

 

[Eric Sosman]

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)
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

Now let's see the list of compilers with 16-bit ints,
the list of compilers that support `void main()', the list
of compilers where `long' and `int' have the same range,
the list of compilers where converting a pointer to an `int'
and back does no harm, the list of compilers that allocate
unrelated `static' variables in adjacent cells in the order
declared, ...

You can generate lists of this kind for pretty much any
feature. The list of left-handed people is long; does that
mean it's wise to assume the next person you meet will be
left-handed?

 

[Jean-Marc Bourguet]

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

It is supported by

4) gcc (versions later than 3.4) (Unix)

I don't think GCC team would like the feature to be used more than it is
already; they consider it obsolete for at least 5 years:

http://gcc.gnu.org/onlinedocs/gcc-3...-only-headers.html#Obsolete once-only headers

Yours,

 

[Kenny McCormack]

Now let's see the list of compilers with 16-bit ints,
the list of compilers that support `void main()', the list
of compilers where `long' and `int' have the same range,
the list of compilers where converting a pointer to an `int'
and back does no harm, the list of compilers that allocate
unrelated `static' variables in adjacent cells in the order
declared, ...

You can generate lists of this kind for pretty much any
feature. The list of left-handed people is long; does that
mean it's wise to assume the next person you meet will be
left-handed?

As I'm entirely sure you are well aware, you are acting like these are
obscure compilers. It'd be like including a list of major software
manufactures that included obscure names like IBM and Microsoft, and
then acting like the list was irrelevant.

 

[Charlie Gordon]

"jacob navia" <[email protected]> a écrit dans le message de
[email protected]...
[...]

Why not

#pragma once

Chqrlie?

As others have mentioned, portability is an issue.
You insisted that this pragma is supported by many compilers, among which
gcc.
I cannot find any mention of it in the documentation for my current gcc
version 4.1.x.
If they support if, it is undocumented and probably deprecated.

So I will not use it..

 

[Richard]

"jacob navia" <[email protected]> a écrit dans le message de
[email protected]...
[...]

Why not

#pragma once

Chqrlie?

As others have mentioned, portability is an issue.
You insisted that this pragma is supported by many compilers, among which
gcc.
I cannot find any mention of it in the documentation for my current gcc
version 4.1.x.
If they support if, it is undocumented and probably deprecated.

So I will not use it..

Then don't. Easy. But for many C programmers who daily weigh up the
benefits of standard adherent C and "mainstream adopted" C it is not
such an easy decision. If I was building a code base for the main 3 PC
OS platforms and all the mainstream compilers used this pragma I know I
would use it.

 

[Charlie Gordon]

"jacob navia" <[email protected]> a écrit dans le message de [email protected]...
[...]

Why not

#pragma once

Chqrlie?

As others have mentioned, portability is an issue.
You insisted that this pragma is supported by many compilers, among which
gcc.
I cannot find any mention of it in the documentation for my current gcc
version 4.1.x.
If they support if, it is undocumented and probably deprecated.

So I will not use it..

Then don't. Easy. But for many C programmers who daily weigh up the
benefits of standard adherent C and "mainstream adopted" C it is not
such an easy decision. If I was building a code base for the main 3 PC
OS platforms and all the mainstream compilers used this pragma I know I
would use it.

I cannot say I disagree. I for instance started using snprintf long before
C99 made it standard.
In this case, this pragma is not exactly mainstream, and not particularly
elegant.

What really sucks is the inability do do conditional compilation during
translation phase 7.

The compiler would know about defined structs, typedefs, functions and other
objects.

What would prevent extending the grammar in order to support such things as:

if (!_Defined(size_t)) {
typedef unsigned int size_t;
}

at global level ?

 

[Keith Thompson]

"jacob navia" <[email protected]> a écrit dans le message de
[email protected]...
[...]

Why not

#pragma once

Chqrlie?

As others have mentioned, portability is an issue.
You insisted that this pragma is supported by many compilers, among which
gcc.
I cannot find any mention of it in the documentation for my current gcc
version 4.1.x.
If they support if, it is undocumented and probably deprecated.

So I will not use it..

Then don't. Easy. But for many C programmers who daily weigh up the
benefits of standard adherent C and "mainstream adopted" C it is not
such an easy decision. If I was building a code base for the main 3 PC
OS platforms and all the mainstream compilers used this pragma I know I
would use it.

It saves a little typing, at the expense of losing any guarantee that
it will continue to be supported, or even that it works exactly the
way you think it does. (As Chqrlie and I have both pointed out, gcc
doesn't even document it.) I don't see any great benefit from that.

 

[Richard Harter]

"jacob navia" <[email protected]> a écrit dans le message de
[email protected]...
[...]
Why not

#pragma once

Chqrlie?

As others have mentioned, portability is an issue.
You insisted that this pragma is supported by many compilers, among which
gcc.
I cannot find any mention of it in the documentation for my current gcc
version 4.1.x.
If they support if, it is undocumented and probably deprecated.

So I will not use it..

Then don't. Easy. But for many C programmers who daily weigh up the
benefits of standard adherent C and "mainstream adopted" C it is not
such an easy decision. If I was building a code base for the main 3 PC
OS platforms and all the mainstream compilers used this pragma I know I
would use it.

It saves a little typing, at the expense of losing any guarantee that
it will continue to be supported, or even that it works exactly the
way you think it does. (As Chqrlie and I have both pointed out, gcc
doesn't even document it.) I don't see any great benefit from that.

As a matter of curiosity, why can't/don't C implementations use a
#require directive that includes a file if and only if it has not
already been included? Is there something in the standard that
precludes it? Is there some subtle problem with having it? It
seems like such an obvious solution that it is odd that it wasn't
added long ago.

As a further note, here is something that can happen with the
standard hack even though it shouldn't. Our hero created an
include file, call it foo.h. It started:

#ifndef HAVE_FOO_H
#define HAVE_FOO_H

Inside the include file there were various definitions and
prototypes, all prefixed with foo_. In due course our hero
wanted a new version of the include file called bar.h. It looked
just the same as foo.h except that foo_ was replaced with bar_.
What he did was copy foo.h into bar.h and do a global edit
replacing foo_ by bar_ ... with a case sensitive editor, of
course.

He didn't notice that the magic control name in the beginning
didn't change. And, of course, the bar software worked fine.
All went well until one day when he decided to use both the foo
software and the bar software in one package. Oops.

Perhaps our hero doesn't deserve too much sympathy. Still his
little problem points out a problem. The standard technique is a
hack. It depends upon programmers using naming conventions for
an arbitrary label, conventions that can lead to unexpected
problems.


Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
But the rhetoric of holistic harmony can generate into a kind of
dotty, Prince Charles-style mysticism. -- Richard Dawkins

 

[jacob navia]

As a matter of curiosity, why can't/don't C implementations use a
#require directive that includes a file if and only if it has not
already been included?

This is *exactly* what

#pragma once

does. It will make that a file
is not included again, what is the same as
#require

 

[Flash Gordon]

jacob navia wrote, On 28/09/07 22:27:
It could be done since implementing it would not affect strictly
conforming programs.

This is *exactly* what

#pragma once

does. It will make that a file
is not included again, what is the same as
#require

No, it is not the same as "#pragma once". "#pragma once" is something
you put in the header to prevent it being included more than once.
"#require" is an alternative to "#include" that you use in order to
include a header only if it has not been included already.

Of course, this all assumes the definition of "#pragma once" that you
are familiar with and the concept of "require" that I am slightly
familiar with from another language.

 

[Ben Bacarisse]

"jacob navia" <[email protected]> a écrit dans le message de
[email protected]...
[...]
Why not

#pragma once

As others have mentioned, portability is an issue.

It saves a little typing, at the expense of losing any guarantee that
it will continue to be supported, or even that it works exactly the
way you think it does.

As a matter of curiosity, why can't/don't C implementations use a
#require directive that includes a file if and only if it has not
already been included?

<off topic>
gcc has #import that has that meaning.

Obviously similarly encumbered with portability issues. It would be a
benefit, IMHO, to have an agreed and standard mechanism.
</off topic>

 

[Jean-Marc Bourguet]

(As Chqrlie and I have both pointed out, gcc doesn't even document it.)

I think I've pointed out that it is documented, in the "obsolete feature"
section of the CPP manual. I've digged a little further, and pragma once
and import where already considered obsolete by gcc for 2.95.3...

Yours,

 

[Chris Torek]

I think I've pointed out that it is documented, in the "obsolete feature"
section of the CPP manual. I've digged a little further, and pragma once
and import where already considered obsolete by gcc for 2.95.3...

Incidentally, the reason they were added and then obsoleted may
be illustrative.

Consider the following expanded source code fragment:

#include <some/path/file.h>
#include <another/header.h>
#include <alternative/path/file.h>

which is the result of:

#include <some/path/file.h>

where the "file.h" in question begins with:

#include <another/header.h>

and "header.h" begins with:

#include <alternative/path/file.h>

As it happens, <alternative/path/file.h> is another name for
the file <some/path/file.h>.

If file.h contains a "#pragma once" directive, does this prevent
the double inclusion of the file under the alternative name
<alternative/path/file.h>? If so, why? If not, why not?

If file.h begins with:

#ifndef H_USUAL_PATH_TO_FILE_H
#define H_USUAL_PATH_TO_FILE_H
... contents of file.h ...
#endif

then, regardless of whether you:

#include <usual/path/file.h>
or:
#include <some/path/file.h>
or:
#include <alternative/path/file.h>

the actual contents get included exactly once. This is true whether
or not those files are links, symbolic links, or copies. GCC's
implementation of "#pragma once" attempted, at some point at least,
to use Unix/POSIX <dev,inode> pairs to uniquely identify files, so
that links and symbolic links were handled correctly, but as it
turns out, this fails when the file is on an NFS file server under
two different mount points. In this case, the files appeared to
be different, as if the two names specified copies of the file.

One could, perhaps, run something like an MD5 checksum on the entire
contents of the header. The chances of two different headers having
the same MD5 sum are low enough to disregard. But it seems simpler
to use header guards, which work even in the presence of links,
symlinks, copies, and NFS file servers.

 

[Philip Potter]

Incidentally, the reason they were added and then obsoleted may
be illustrative.

Consider the following expanded source code fragment:

#include <some/path/file.h>
#include <another/header.h>
#include <alternative/path/file.h>

which is the result of:

#include <some/path/file.h>

where the "file.h" in question begins with:

#include <another/header.h>

and "header.h" begins with:

#include <alternative/path/file.h>

As it happens, <alternative/path/file.h> is another name for
the file <some/path/file.h>.

If file.h contains a "#pragma once" directive, does this prevent
the double inclusion of the file under the alternative name
<alternative/path/file.h>? If so, why? If not, why not?

It's interesting that this argument applies not only to #pragma once but
also Objective-C style #import directives. However, is it often the case
that when one is compiling a project, one uses the same file referred to
through two different NFS mount points? Is it so much of a problem that
#include guards are definitely better? After all, they have their own
quirks and disadvantages - not least of which, the possibility for
accidental E* namespace invasion, and the possibility of different
headers using the same #defines.

 

[Ben Pfaff]

[argument against #pragma once]

It's interesting that this argument applies not only to #pragma once
but also Objective-C style #import directives.

The manual for GCC's C preprocessor gives a different argument
against #import:

In the Objective-C language, there is a variant of
`#include' called `#import' which includes a file, but does
so at most once. If you use `#import' instead of `#include',
then you don't need the conditionals inside the header file
to prevent multiple inclusion of the contents. GCC permits
the use of `#import' in C and C++ as well as Objective-C.
However, it is not in standard C or C++ and should therefore
not be used by portable programs.

`#import' is not a well designed feature. It requires the
users of a header file to know that it should only be
included once. It is much better for the header file's
implementor to write the file so that users don't need to
know this. Using a wrapper `#ifndef' accomplishes this goal.

 

[CBFalconer]

.... snip ...

It's interesting that this argument applies not only to #pragma
once but also Objective-C style #import directives. However, is
it often the case that when one is compiling a project, one uses
the same file referred to through two different NFS mount points?
Is it so much of a problem that #include guards are definitely
better? After all, they have their own quirks and disadvantages -
not least of which, the possibility for accidental E* namespace
invasion, and the possibility of different headers using the same
#defines.

This cannot occur with #include guards if you use the rule that the
control variable is exactly H_<filenamewith.replacedby_>.

 

[Ben Bacarisse]

This cannot occur with #include guards if you use the rule that the
control variable is exactly H_<filenamewith.replacedby_>.

I think it can:

#include "driedfruit/date.h"
#include "calendar/date.h"

It is impractical to encode the full path name of a header file since
they often move about or get reused in new projects. Of course, if
you do include some more of the path name in the guard you can hit the
opposite problem: including a file twice when the guard should have
prevented it simply because it happens to be in two places.

Ultimately the only solution is to take care and understand the
mechanism.

 

[CBFalconer]

I think it can:

#include "driedfruit/date.h"
#include "calendar/date.h"

In that case the '/' will cause problems. I meant filenames
without paths. Paths are normally controlled through unmentioned
compiler options anyhow. And I have little sympathy for people who
give different files the same name.

 

[Chris Torek]

... I meant filenames without paths. Paths are normally controlled
through unmentioned compiler options anyhow.

Well, some of them, in some cases.

And I have little sympathy for people who give different files
the same name.

This happens for various reasons. Sometimes a single file gets
two names: "the name we invented" (back in the 1900s perhaps, as
<foo.h>) and "the name in the Standard" (C or POSIX or whatever,
as decided in the 2000s, now <sys/foo.h>). Sometimes two different
modules have files with the same name but a different purpose:
perhaps the Zorg library has "evil.c" and "evil.h" for creating
evil, while the metering library has "evil.c" and "evil.h" for
measuring evil. If you need to meter your evil as well as create
it, you might want to use both.

Of course, name conflicts in general are an issue C pretends it
can ignore -- as we see today with various packages that define
their own BOOL or Bool or Boolean or boolean_t types, for instance.