Re: Macro does not work in source code.
On Aug 1, 9:11 am, "Alf P. Steinbach"
<alf.p.steinbach:use...@gmail.com> wrote:
On 01.08.2011 08:58, Paul Brettschneider wrote:
wrote:
On 01.08.2011 00:48, Alf P. Steinbach wrote:
No, "#pragma once" is not an MS thing.
And as I'm testing now MinGW g++ 4.x supports "#pragma once".
It's a de facto standard: AFAIK the C++ standardization
committee is the only actor who has not adopted it.
Except for all of the others. Most of the C++ compilers I've
used in the past didn't support it. (The only C++ compilers I
use currently are VC++ and g++.)
<url:http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC8>
<url:http://en.wikipedia.org/wiki/Pragma_once>
However, the GNU docs references above says "#pragma once" is obsolete.
That's a pretty weird statement.
Oh, the more recent GNU docs, for version 4.6, do not say obsolete:
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/cpp/Alternatives-to-Wrapper-
_0023ifndef.html#Alternatives-to-Wrapper-_0023ifndef
Isn't "[W]e recommend you do not use them in new programs" a mild form of
saying just that?
I have nothing against extensions (for example no_return or format string
specifiers in C-like IO functions are very useful), but if there is no
advantage over the standard way, I fail to see the point.
The pragma is generally safer than include guards, it gives less visual
clutter, and, being higher level, can even be faster.
The pragma isn't nearly as safe as include guards, since it
doesn't work generally. If you want your code to be portable,
you need the include guards. And once you have the include
guards, the pragma doesn't buy you anything.
FWIW, the standards committee rejected it because it can't be
made to work reliably on networked machines. (I'm not sure I
agree with their decision. The cases where it doesn't work
reliably are pretty perverse, and would probably cause problems
for the humans managing the system. On the other hand, trying
to find standardese which let the implementation off the hook in
such cases doesn't seem trivial.)
The reason for the generally improved safety is that it does not rely on
the programmer selecting a truly unique header guard symbol.
That's a different problem. For starters, there's no reason why
the programmer should be selecting the guard symbol. That's the
environment's job, and it's relatively simple for the
environment to come up with something at least as unique as the
name of an unnamed namespace. I'm using vim, hardly the most
state of the art editor, and when I open a new .hh file, I get
the include guards already generated, with a lot of truly random
letters at the end.
There is one situation where instead include guards can be safer, namely
in the context of symbolic links to files. But that's a rare situation,
and mostly it's just a question of Quality of Implementation. g++ once
had a problem here, but it was fixed.
Symbolic links are easy, since you can resolve them to the true
name. Hard links are more difficult; you need to keep track of
the device and inode number. And remote mounted files are
impossible.
Especially in this
case were it was suggested up-thread to use include guards *and* the
#pragma. That's one more line for nothing. Old cruft like this should be
supported for compatibility reasons, but also deprecated to make a point.
On the contrary, "#pragma once" is probably what one should use for new
code -- IN SPITE OF NOT BEING FORMALLY STANDARD. ;-)
Only if you don't care if your code works on machines other than
Windows and Linux.
--
James Kanze