Re: #pragma once in ISO standard yet?
On Dec 16, 4:16 pm, akfmn...@t-online.de (Andre Kaufmann) wrote:
James Kanze wrote:
On Dec 15, 6:16 pm, Andre Kaufmann <akfmn...@t-online.de> wrote:
[...]
I'd rather use an intelligent version control system, rather
than have to be sure of updating manually at the correct moment.
Remember that intelligent version control systems, like
Clearcase, behave as file servers, so that you always see the
version you're supposed to see.
I do use version control systems too. Though I have always a
local view of the source files on my local hard disk.
Which means that you can't discuss your work with collegues.
Not a very good practice.
For that matter, I don't think I've ever worked at a place where
the source files were on a local disk. What do you do when you
start discussing them with a collegue, on his machine?
And what will you do if your colleague changes the source file
during compilation ?
If I've got the file checked out, he can't write it. And of
course, for the files I don't have checked out, I see a stable
version.
Anyways better to compile on a local machine than compiling
over network, or am I totally wrong ?
Totally wrong. Complete builds would take forever on a single
machine. Your local remakes, of course, will all be compiled on
your machine, but the only way to be sure that you've got the
right versions of all of the headers is to go through some sort
of central server.
Perhaps you've got me wrong. The source repository is a
central database. But before you compile you get all your
sources from this central database, distributed builds will
make this too. So they are compiled locally. I can't hardly
think of multiple developers developing and compiling directly
on a central database, when some of them are editing the
sources.
All I can say is that I've never seen a system with local copies
which worked reliably. You see what the file server decides
that you should see. The file server is the version control
system. As versions evolve, you see newer versions.
Obviously, you are informed that the change will take place.
But it doesn't involve copying some twenty or thirty different
files to over a hundred different machines, hoping that they're
all up at the moment you decide to do the copy, and that nothing
goes wrong.
If you have some kind of distributed build system, to gain
some speed, you will have always have some kind of local view
too. Otherwise you would compiled directly over network,
which IMHO would make compilation painfully slow.
I've rarely compiled against local files, and only in very small
projects. And compilation isn't particularly slow. It is, in
fact, a lot faster than searching down the problems because you
somehow ended up with incompatible versions.
Must any nasty hardware construction/topology be supported
or should the hardware infrastructure be adopted to the
compiler?
No. That's exactly why `#pragma once' doesn't work: it
would require some nasty topology to work, rather than using
something sensible.
Neither header files are IHMO sensible or compiling directly
over network. If the central build machine or the developers
would compile over the network directly, they would have to
lock the whole source repository / directories during
compilation.
Obviously, you've never used a modern version control system,
which works like a file server. You really should give
Clearcase (or something like it) a try.
[...]
What's the point in having #pragma once, if you also need
include guards.
That this will also work on hardware topologies, where #pragma
once can't be used. But as I wrote to #pragma once could be
extended simply by an identifier, which should work always as
good as header guards
And I said: why bother? What's the difference?
[...]
#pragma once doesn't offer any speed gain. There is
absolutely no difference in build times with g++ when you
use include guards instead of #pragma once. Including over
a slow network.
If you do include the header file only once there can't be a
speed gain. Otherwise g++ will always open the header file
multiple times, but why should it ?
It doesn't. No modern compiler does. The only time it has to
open the file more than once is when it is unsure if it is the
same file.
[...]
The experience of the people at gcc seems to indicate the
opposite.
As I already wrote, IMHO not the fault of the compiler but the
OS or hardware topology, which makes it impossible to check if
2 file paths are pointing to the same file. If the OS can't
check this reliably, it's IMHO a security problem at all.
You may think it's a security problem, but it's the way things
work in real life. Neither SMB nor NFS have a means of
asserting whether two pathnames are identical. So "#pragma
once" can't be made to work reliably under Windows nor under
Unix. The probability of a feature being adopted which can't be
implemented reliably under Unix nor under Windows is pretty
small.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]