By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,703 Members | 1,215 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,703 IT Pros & Developers. It's quick & easy.

standard change

P: n/a
There must be some change in the standard because I ran into this error when
I put this line in a header.
# pragma once
I only wanted the headers to be included once. The compiler said something
about obsolete.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 14 '05 #1
Share this Question
Share on Google+
31 Replies


P: n/a
* Thus spoke Bill Cunningham <no****@nspam.net>:

Hallo,
I only wanted the headers to be included once.


Use »include guards«. They are standard, #pragma once is not.
Wolfgang.
--
"Erfahrungen -- das sind die vernarbten Wunden unserer Dummheit."
-- John Osborne
Nov 14 '05 #2

P: n/a
"Bill Cunningham" <no****@nspam.net> writes:
There must be some change in the standard because I ran into this
error when I put this line in a header.
# pragma once
I only wanted the headers to be included once. The compiler said
something about obsolete.


The behavior of pragmas is implementation-defined (with a few exceptions
in C99, but `#pragma once' is not one of them). Therefore, the compiler
implementor can change the meaning of or deprecate certain pragmas
without violating the standard.

<OT>
In case the compiler in question is the GCC C compiler: Despite being
marked obsolete in the current version, `#pragma once' will continue to
work in future versions.

To quote from <http://gcc.gnu.org/gcc-3.4/changes.html>:
| File handling in the preprocessor has been rewritten. GCC no longer
| gets confused by symlinks and hardlinks, and now has a correct
| implementation of #import and #pragma once. These two directives have
| therefore been un-deprecated.
</OT>

<even more OT>
Shouldn't the antonym of "deprecate" be "precate" instead of
"un-deprecate"? ;)
</even more OT>

Martin
Nov 14 '05 #3

P: n/a
Bill Cunningham wrote:
There must be some change in the standard because I ran into this error when
I put this line in a header.
# pragma once
I only wanted the headers to be included once. The compiler said something
about obsolete.


Until C99, no particular #pragma had a meaning defined by the standard.
With the new standard, we have a handful of #pragmas with meanings hoped to
have more than implementation-specific meanings. These include
#pragma STDC FP_CONTRACT on-off-switch
#pragma STDC FENV_ACCESS on-off-switch
#pragma STDC CX_LIMITED_RANGE on-off-switch
where on-off-switch is one of ON, OFF, and DEFAULT
These 9 forms may have been supplemented by others that I don't know, but
#pragma once
has _never_ been standard. Since system headers are, at least from C99,
idempotent, and with normal guards your headers can be made effectively so,
there is no need for '#pragma once' as you describe it.


--
Martin Ambuhl
Nov 14 '05 #4

P: n/a
Lcc-win32 accepts and implements #pragma once.

It is a useful thing: This include header file will never be
loaded again.

Yes, lcc-win32 can't determine if in a complex
network setup a share path of
\\server23\srcdir34\project56\patch45876.h
is the same physical file as
\\serge\prj\patch45876.h

So it will not work. Let's keep it simple. It will not
test for symlinks either.
Nov 14 '05 #5

P: n/a
Martin Dickopp wrote:
.... snip ...
Shouldn't the antonym of "deprecate" be "precate" instead of
"un-deprecate"? ;)


In the spirit of flammable, inflammable, uninflammable, I offer
dedeprecate :) Just speaking English as she is spoke :-)

None of de flames please.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #6

P: n/a
On 01 Feb 2004 21:00:34 +0100, Martin Dickopp
<even more OT>
Shouldn't the antonym of "deprecate" be "precate" instead of
"un-deprecate"? ;)
</even more OT>


Maybe if it were pronounced "dee-precate"... although then I might
vote for re-precate ;-)
-leor

Nov 14 '05 #7

P: n/a
On 01 Feb 2004 21:00:34 +0100, Martin Dickopp
<ex****************@zero-based.org> wrote:
To quote from <http://gcc.gnu.org/gcc-3.4/changes.html>:
| File handling in the preprocessor has been rewritten. GCC no longer
| gets confused by symlinks and hardlinks, and now has a correct
| implementation of #import and #pragma once. These two directives have
| therefore been un-deprecated.
</OT>


I'll continue to deprecate it anyway <g>.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #8

P: n/a
In 'comp.lang.c', "jacob navia" <ja***@jacob.remcomp.fr> wrote:
Lcc-win32 accepts and implements #pragma once. It is a useful thing: This include header file will never be
loaded again.


What's wrong with the standard 'guard' trick?

#ifndef H_XXX
#define H_XXX

....

#endif /* guard */

I have automated it so that the macro tends to be unique.

H_<company or initials>_<file name>_<YYYY><MM><DD><hh><mm><ss>

From my 'str.h':

#ifndef H_AETA_STR_20021226104232
#define H_AETA_STR_20021226104232

....

#endif /* guard */

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Nov 14 '05 #9

P: n/a
Emmanuel Delahaye <em**********@noos.fr> writes:
In 'comp.lang.c', "jacob navia" <ja***@jacob.remcomp.fr> wrote:
Lcc-win32 accepts and implements #pragma once.

It is a useful thing: This include header file will never be
loaded again.


What's wrong with the standard 'guard' trick?

#ifndef H_XXX
#define H_XXX

...

#endif /* guard */


Nothing, really.

The guard trick does impose a slight performance penalty, since it
requires the compiler to re-process the include file every time it's
referenced (unless the compiler is smart enough to recognize it and
optimize it out). Using "#pragma once" can avoid this overhead
(assuming the compiler is always right about whether it's already seen
a given header -- think about symlinks) at the expense of portability.

Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #10

P: n/a
In article <news:ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:
The [include] guard trick does impose a slight performance penalty ...
(unless the compiler is smart enough to recognize it and
optimize it out). Using "#pragma once" can avoid this overhead
(assuming the compiler is always right about whether it's already seen
a given header -- think about symlinks) at the expense of portability.
For what it is worth, gcc -- which is perhaps the main compiler for
which "#pragma once" is used -- *also* does precisely the above
"optimizing out".

I have not looked at the gcc preprocessor code in a while, but
it would be quite reasonable for it to have a data structure
containing a "system unique file ID" (mount point and inode on
a Unix-like system) and "once-only" flag:

struct include_file_info {
md_fileid_type file_id;
int onceonly;
...
};

Then, "#pragma once" sets:

file->onceonly = 1;

but so does "#ifndef GUARD / #define GUARD / ... / #endif", using
one more field in the "include file info":

file->guard_id = identifier_name;

Now "#include" processing just does:

fi = lookup_file_info(...);
if (fi != NULL &&
(fi->onceonly || (fi->guard_id && cpp_ifdef(fi->guard_id))))
... skip the file ...

which means that "#pragma once" is only very slightly more efficient
anyway (because the #ifndef identifier need not be looked up).
Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.


Perhaps; but what about a compiler for which this means "turn on
ce", as opposed to "#pragma offce" (turning off C.E., whatever that
is)? :-) (GCC1 used to recognize *all* #pragma constructs, treating
them as requests to run rogue or nethack.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #11

P: n/a
Keith Thompson wrote:
Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.


A compiler might legitimately (or, at least, legally!) recognise #pragma
once, but with different semantics. Ouch.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #12

P: n/a
Richard Heathfield <do******@address.co.uk.invalid> writes:
Keith Thompson wrote:
Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.


A compiler might legitimately (or, at least, legally!) recognise #pragma
once, but with different semantics. Ouch.


True -- just as a non-conforming compiler can define __STDC__ without
(further) violating the standard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #13

P: n/a
Richard Heathfield <do******@address.co.uk.invalid> wrote in message news:<bv**********@hercules.btinternet.com>...
Keith Thompson wrote:
Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.


A compiler might legitimately (or, at least, legally!) recognise #pragma
once, but with different semantics. Ouch.

Presumably a Spanish C compiler will include your header file eleven times. ;-)
Nov 14 '05 #14

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
Emmanuel Delahaye <em**********@noos.fr> writes:
In 'comp.lang.c', "jacob navia" <ja***@jacob.remcomp.fr> wrote:
Lcc-win32 accepts and implements #pragma once.

It is a useful thing: This include header file will never be
loaded again.


What's wrong with the standard 'guard' trick?

#ifndef H_XXX
#define H_XXX

...

#endif /* guard */


Nothing, really.

The guard trick does impose a slight performance penalty, since it
requires the compiler to re-process the include file every time it's
referenced (unless the compiler is smart enough to recognize it and
optimize it out). Using "#pragma once" can avoid this overhead
(assuming the compiler is always right about whether it's already seen
a given header -- think about symlinks) at the expense of portability.

Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.


A scheme that safely avoids re-preprocessing an include file in most
cases is not too too difficult. A very simple scheme would be to check
that a file starts with #ifndef, has no matching #else or #elif, and
ends with the matching #endif. That would probably cover 90% of all the
cases at minimal cost and doesn't force the user to use non-portable
code.
Nov 14 '05 #15

P: n/a
Richard Heathfield <do******@address.co.uk.invalid> wrote in message news:<bv**********@hercules.btinternet.com>...
Keith Thompson wrote:
Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.


A compiler might legitimately (or, at least, legally!) recognise #pragma
once, but with different semantics. Ouch.

Presumably a Spanish C compiler will include your header file eleven times. ;-)
Nov 14 '05 #16

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.


OTOH, a compiler is free to assign completely different semantics to
"#pragma once", so its usage is never safe in portable code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #17

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Richard Heathfield <do******@address.co.uk.invalid> writes:
Keith Thompson wrote:
> Using "#pragma once" in combination with the guard trick is probably
> reasonable if you're careful about it; a compiler that doesn't
> recognize "#pragma once" is required to ignore it.


A compiler might legitimately (or, at least, legally!) recognise #pragma
once, but with different semantics. Ouch.


True -- just as a non-conforming compiler can define __STDC__ without
(further) violating the standard. ^^^^^^^

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Then, it is, *by definition* a conforming compiler ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #18

P: n/a
On 3 Feb 2004 02:21:49 GMT, Chris Torek <no****@torek.net> wrote:
In article <news:ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:
The [include] guard trick does impose a slight performance penalty ...
(unless the compiler is smart enough to recognize it and
optimize it out). Using "#pragma once" can avoid this overhead
(assuming the compiler is always right about whether it's already seen
a given header -- think about symlinks) at the expense of portability.


For what it is worth, gcc -- which is perhaps the main compiler for
which "#pragma once" is used -- *also* does precisely the above
"optimizing out".

The first place I encountered it was in Microsoft headers.

All the compilers I use have the capability of using precompiled
headers, which is even more efficient than #pragma once.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #19

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Richard Heathfield <do******@address.co.uk.invalid> writes:
Keith Thompson wrote:

> Using "#pragma once" in combination with the guard trick is probably
> reasonable if you're careful about it; a compiler that doesn't
> recognize "#pragma once" is required to ignore it.

A compiler might legitimately (or, at least, legally!) recognise #pragma
once, but with different semantics. Ouch.


True -- just as a non-conforming compiler can define __STDC__ without
(further) violating the standard. ^^^^^^^

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Then, it is, *by definition* a conforming compiler ;-)


I see the smiley, but just to make sure I wrote what I actually meant
....

A compiler that, for example, doesn't support prototypes is obviously
non-conforming. If it defines __STDC__, it doesn't become any more
non-conforming than it already was.

The standard requires conforming implementations to define __STDC__,
but it can't forbid non-conforming implementations to do so.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #20

P: n/a
Keith Thompson wrote:
.... snip ...
The standard requires conforming implementations to define __STDC__,
but it can't forbid non-conforming implementations to do so.


However, the marketplace can. A compiler system that fails to
conform normally does so for a good reason, and thus needs to
cooperate in warning its users of non-standardisms. Thus there is
no incentive for defining __STDC__ in illsuited places.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #21

P: n/a
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Keith Thompson wrote:

... snip ...

The standard requires conforming implementations to define __STDC__,
but it can't forbid non-conforming implementations to do so.


However, the marketplace can. A compiler system that fails to
conform normally does so for a good reason, and thus needs to
cooperate in warning its users of non-standardisms. Thus there is
no incentive for defining __STDC__ in illsuited places.


Actually, the market place has acted in the opposite direction: because
__STDC__ was almost exclusively used to test whether the compiler
supports prototypes, some compilers supporting prototypes define it even
when invoked in non-conforming mode. Try the following example while
invoking your compiler in non-conforming mode and see what you get.

fangorn:~/tmp 42> cat test.c
#include <stdio.h>

int main()
{
#if __STDC__ == 1
puts("The compiler pretends to be standard-conforming.");
#else
puts("The compiler has been invoked in non-conforming mode.");
#endif
return 0;
}
fangorn:~/tmp 43> gcc test.c
fangorn:~/tmp 44> ./a.out
The compiler pretends to be standard-conforming.

Some compilers do the right thing and still define __STDC__ in
non-conforming mode, but give it a different value than 1. Programs that
assume that prototypes are available if __STDC__ is merely defined still
work as intended.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #22

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
>Richard Heathfield <do******@address.co.uk.invalid> writes:
>> Keith Thompson wrote:
>>
>> > Using "#pragma once" in combination with the guard trick is probably
>> > reasonable if you're careful about it; a compiler that doesn't
>> > recognize "#pragma once" is required to ignore it.
>>
>> A compiler might legitimately (or, at least, legally!) recognise #pragma
>> once, but with different semantics. Ouch.
>
>True -- just as a non-conforming compiler can define __STDC__ without
>(further) violating the standard. ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Then, it is, *by definition* a conforming compiler ;-)


I see the smiley, but just to make sure I wrote what I actually meant
...

A compiler that, for example, doesn't support prototypes is obviously
non-conforming. If it defines __STDC__, it doesn't become any more
non-conforming than it already was.


That's not what you wrote above, but it's still wrong. The C standard
kindly asks non-conforming compilers not to define __STDC__ as 1. They
can still define __STDC__ as anything else.
The standard requires conforming implementations to define __STDC__,
but it can't forbid non-conforming implementations to do so.


Again, the standard doesn't even try to get a monopoly on __STDC__, it's
only the value 1 that it reserves for this macro.

But your whole analogy with "#pragma once" is broken, because the
standard is not reserving any semantics for it. So, two *conforming*
implementations can legitimately and with bona fide assign different
semantics to this pragma.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #23

P: n/a
Dan Pop wrote:
CBFalconer <cb********@yahoo.com> writes:
Keith Thompson wrote:

... snip ...

The standard requires conforming implementations to define __STDC__,
but it can't forbid non-conforming implementations to do so.


However, the marketplace can. A compiler system that fails to
conform normally does so for a good reason, and thus needs to
cooperate in warning its users of non-standardisms. Thus there is
no incentive for defining __STDC__ in illsuited places.


Actually, the market place has acted in the opposite direction: because
__STDC__ was almost exclusively used to test whether the compiler
supports prototypes, some compilers supporting prototypes define it even
when invoked in non-conforming mode. Try the following example while
invoking your compiler in non-conforming mode and see what you get.

fangorn:~/tmp 42> cat test.c
#include <stdio.h>

int main()
{
#if __STDC__ == 1
puts("The compiler pretends to be standard-conforming.");
#else
puts("The compiler has been invoked in non-conforming mode.");
#endif
return 0;
}
fangorn:~/tmp 43> gcc test.c
fangorn:~/tmp 44> ./a.out
The compiler pretends to be standard-conforming.

Some compilers do the right thing and still define __STDC__ in
non-conforming mode, but give it a different value than 1. Programs
that assume that prototypes are available if __STDC__ is merely
defined still work as intended.


Aren't you confusing "standard-conforming" with "has extensions"?
I believe than any program that gcc compiles successfully with -W
-Wall -ansi -pedantic will also compile with the same gcc and no
flags.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #24

P: n/a
CBFalconer wrote:
I believe than any program that gcc compiles successfully with -W
-Wall -ansi -pedantic will also compile with the same gcc and no
flags.


Counterexample:

$ cat gcc.c
int main(int typeof, char **b) { return typeof[b] != 0; }
$ gcc -W -Wall -ansi -pedantic gcc.c
$ gcc gcc.c
gcc.c:1: parse error before "typeof"
gcc.c: In function `main':
gcc.c:1: parse error before "typeof"

Jeremy.
Nov 14 '05 #25

P: n/a
Jeremy Yallop wrote:
CBFalconer wrote:
I believe than any program that gcc compiles successfully with -W
-Wall -ansi -pedantic will also compile with the same gcc and no
flags.


Counterexample:

$ cat gcc.c
int main(int typeof, char **b) { return typeof[b] != 0; }
$ gcc -W -Wall -ansi -pedantic gcc.c
$ gcc gcc.c
gcc.c:1: parse error before "typeof"
gcc.c: In function `main':
gcc.c:1: parse error before "typeof"


OK, so my statement is not strictly true. The above is due to the
use of extended keywords, however, so the error would be better
phrased as:

invalid use of keyword "typeof".

and is an illustration of why such extensions should be kept in
the implementors namespace. C99s use of _Bool and bool are a good
example.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #26

P: n/a
Bill Cunningham wrote:
I only wanted the headers to be included once.
The compiler said something about obsolete.


#ifndef GUARD_FILE_H
#define GUARD_FILE_H 1
// contents of header file
#endif//GUARD_FILE_H

The C preprocessor is smart enough to distinguish
*idempotent* header files from the "guard" macros.
It remembers which header files are idempotent
and will *not* read them again
so your #pragma once is no longer necessary.

Nov 14 '05 #27

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
>Richard Heathfield <do******@address.co.uk.invalid> writes:
>> Keith Thompson wrote:
>> > Using "#pragma once" in combination with the guard trick is probably
>> > reasonable if you're careful about it; a compiler that doesn't
>> > recognize "#pragma once" is required to ignore it.
>>
>> A compiler might legitimately (or, at least, legally!)
>> recognise #pragma once, but with different semantics. Ouch.
>
>True -- just as a non-conforming compiler can define __STDC__ without
>(further) violating the standard. ^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Then, it is, *by definition* a conforming compiler ;-)
I see the smiley, but just to make sure I wrote what I actually meant
...

A compiler that, for example, doesn't support prototypes is obviously
non-conforming. If it defines __STDC__, it doesn't become any more
non-conforming than it already was.


That's not what you wrote above, but it's still wrong. The C standard
kindly asks non-conforming compilers not to define __STDC__ as 1. They
can still define __STDC__ as anything else.


Ok, I was imprecise; I referred to defining __STDC__ (which the
standard doesn't address) when I should have referred to defining
__STDC__ as 1 (which it does). (And yes, that is what I wrote
earlier, but let's not waste everyone's time arguing about it.)
But your whole analogy with "#pragma once" is broken, because the
standard is not reserving any semantics for it. So, two *conforming*
implementations can legitimately and with bona fide assign different
semantics to this pragma.


Strictly speaking, that's true. On the other hand, there are several
compilers, including gcc, that implement "#pragma once" with the
obvious semantics. I know of none that implement it with any other
semantics. I think it's common enough that nobody is likely to
implement "#pragma once" with something radically different from the
existing (implementation-defined) semantics. That's why I wrote
"probably reasonable if you're careful about it" rather than
"perfectly portable and safe".

On the other hand, an old version of gcc responded to all #pragmas by
playing rogue, so assuming limits to compiler perversity isn't
*entirely* safe. (The DS9000 C compiler probably interprets "pragma
#once" as a directive to print the next 11 error messages in Spanish.)

On the other other hand, the guard trick has the advantage of being
portable; the only advantage of "#pragma once" (if it works) is that
it avoids opening the file *on some implementations*, and that's
probably insignificant on modern systems. I don't think I've ever
used "#pragma once" myself.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #28

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
Bill Cunningham wrote:
I only wanted the headers to be included once.
The compiler said something about obsolete.


#ifndef GUARD_FILE_H
#define GUARD_FILE_H 1
// contents of header file
#endif//GUARD_FILE_H

The C preprocessor is smart enough to distinguish
*idempotent* header files from the "guard" macros.
It remembers which header files are idempotent
and will *not* read them again
so your #pragma once is no longer necessary.


Correction: *some* implementations of the C preprocessor are smart
enough to recognize "guard" macros and avoid re-reading the file.

Even for those that aren't quite that smart, though, "#pragma once"
only saves a small amount of overhead; it's probably not worth
worrying about it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #29

P: n/a
Chris Torek wrote:
In article <news:ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:
Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.

Perhaps; but what about a compiler for which this means "turn on
ce", as opposed to "#pragma offce" (turning off C.E., whatever that
is)? :-) (GCC1 used to recognize *all* #pragma constructs, treating
them as requests to run rogue or nethack.)


I guess this is a big QoI issue. But any implementation so bizarre as to
parse once as on_ce is probably asking to be replaced by a Real Compiler. ;)

As for GCC1 and `#pragma's: I guess I'm assuming that's a joke, but I
know odder things have happened in the world of software. And given that
GCC was a tool originally for the Unix-like GNU system (as opposed to
the UNIX-like Linux system), where you might reasonably assume a rogue
or nethack program to exist, well... could you at least say `#pragma
rogue' or `#pragma nethack' to control /which/ it would launch? ;)

--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.
Nov 14 '05 #30

P: n/a
August Derleth wrote:

Chris Torek wrote:
In article <news:ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:
Using "#pragma once" in combination with the guard trick is probably
reasonable if you're careful about it; a compiler that doesn't
recognize "#pragma once" is required to ignore it.

Perhaps; but what about a compiler for which this means "turn on
ce", as opposed to "#pragma offce" (turning off C.E., whatever that
is)? :-) (GCC1 used to recognize *all* #pragma constructs, treating
them as requests to run rogue or nethack.)


I guess this is a big QoI issue. But any implementation so bizarre as to
parse once as on_ce is probably asking to be replaced by a Real Compiler. ;)


While "on ce" may be far-fetched, there are certainly
other plausible meanings for "once:"

#pragma once
int main(void) ...

might mean "the main() function will not be called recursively,
so the compiler can take shortcuts in its calling conventions."

A confusion I actually encountered long ago (long enough
that the details have faded from memory) involved two compilers
that supported a "#pragma align N" directive, where N specified
the desired memory alignment for a variable. Unfortunately,
one compiler interpreted N as asking for N-byte alignment while
the other thought of it as asking for 2**N-byte alignment ...
"#pragma align 3" was clearly in the second compiler's style (and
an error to the first compiler), but "#pragma align 4" was
acceptable and meaningful to both -- with different meanings.

--
Er*********@sun.com
Nov 14 '05 #31

P: n/a
August Derleth <se*@sig.now> writes:
[...]
As for GCC1 and `#pragma's: I guess I'm assuming that's a joke, but I
know odder things have happened in the world of software. And given
that GCC was a tool originally for the Unix-like GNU system (as
opposed to the UNIX-like Linux system), where you might reasonably
assume a rogue or nethack program to exist, well... could you at least
say `#pragma rogue' or `#pragma nethack' to control /which/ it would
launch? ;)


Yes, it was a joke, but it really was implemented that way. It would
first try to run "rogue"; if that failed, it would try to run "hack";
if that failed, it would try to run GNU Emacs displaying the Towers of
Hanoi; if that failed, it would report a fatal error. (I think this
was before "nethack" existed.)

The C90 standard just says that #pragma "causes the implementation to
behave in an implementation-defined manner" (and that unrecognized
pragmas are ignored), so gcc's behavior was conforming, if odd.

Here's an excerpt from the oldest gcc sources I have, version 1.35,
released in 1989 (note the "#if 0"):

#if 0
/* This was a fun hack, but #pragma seems to start to be useful.
By failing to recognize it, we pass it through unchanged to cc1. */

/*
* the behavior of the #pragma directive is implementation defined.
* this implementation defines it as follows.
*/
do_pragma ()
{
close (0);
if (open ("/dev/tty", O_RDONLY, 0666) != 0)
goto nope;
close (1);
if (open ("/dev/tty", O_WRONLY, 0666) != 1)
goto nope;
execl ("/usr/games/hack", "#pragma", 0);
execl ("/usr/games/rogue", "#pragma", 0);
execl ("/usr/new/emacs", "-f", "hanoi", "9", "-kill", 0);
execl ("/usr/local/emacs", "-f", "hanoi", "9", "-kill", 0);
nope:
fatal ("You are in a maze of twisty compiler features, all different");
}
#endif

This version actually handled "#pragma once".

Newer versions of gcc are starting to do something very sensible. All
#pragmas are implemented as "#pragma GCC ..."; if you want to use
"#pragma GCC once", it's unlikely that another compiler will have
defined inconsistent semantics for it. Previously implemented pragmas
are still supported without the "GCC" prefix, but that form is
deprecated.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #32

This discussion thread is closed

Replies have been disabled for this discussion.