Re: #pragma once in ISO standard yet?
On Dec 16, 11:08 pm, akfmn...@t-online.de (Andre Kaufmann) wrote:
James Kanze wrote:
On Dec 16, 1:52 am, akfmn...@t-online.de (Andre Kaufmann) wrote:
Pete Becker wrote:
[...]
As far as I know, all other languages require the programmer
to do the right thing. For different definitions of the
right thing. (Well, Java forbids the programmer to do the
right thing, since the right thing does require keeping the
implementation and the interface specification in two
different files. But from what I understand, Java
programmers have come up with work-arounds for this defect.)
Hm, managed languages. Take for example C#. There aren't any
header files and I don't have even to import or include any
other source file. The modules are separated by name spaces,
rather than per file basis. Java IMHO goes somewhat too far,
separating all objects in a file, IIRC - I'm no Java expert.
Where the objects are really isn't the issue (although the Java
model of one dynamically loaded object file per class is a bit
awkward). The issue is really managing change: changing an
interface requires more management than changing an
implementation. After that, different languages require
different techniques to achieve this end, but having the
interface specification in a separate file from the
implementation is certainly an advantage.
[...]
Whatever arguments there might be, build times is not one.
There are, at least to drop header files at all, which should
boost compilation time a lot.
Interestingly enough, I think just the opposite would be the
effect. The compiler must somehow find the interface
specifications, if it is to check them. If you, as a
programmer, specify which files to look at, it only has to look
at those files. If you don't, it may have to look at a lot more
files.
But there are a lot of other factors to consider. (If I were
designing a development system, it would probably cache most of
the "headers" in a precompiled form in a data base. Something
along the lines of what Visual Age does, or did.)
Pragma once would perhaps only have minor effects.
It has no effect with g++. Even when the headers are served up
over a slow network.
[...]
None of the OS's I know can do this. There's no support for
it in either NFS nor SMB, so practically, it isn't
implementable if the files are mounted using one of those
protocols.
Well, you could add some kind of hash cookie to a file and
mark it or add another cookie file in the same directory. NTFS
supports for example multiple streams for a single file. As
soon as the file is marked, only the cookie must be read to
check if the 2 file paths are identical. Other variant would
be to lock the files during compilation of a single module and
check if the files are locked by the same process on
reopening. I know these solutions have other (big) downsides,
should be only an example how it could be solved, if the path
couldn't really be canonicalized and resolved.
It would be fairly easy to support uniqueness at the OS level
for local files. And it really wouldn't be that hard to provide
for it in the protocols used for handling remote files. At
present, however, neither does provide for this, and somehow, I
get the feeling that they're not going to change just because
C++ wants them to.
But let's forget #pragma once, better drop header files at all.
Have a look at David Vandevoorte's proposal for modules.
--
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 ]