Re: Benign typedef definition



On 2009-03-05, Keith Thompson <kst-u@xxxxxxx> wrote:
Spiros Bousbouras <spibou@xxxxxxxxx> writes:
[...]
If the objective is to eliminate multiple inclusions of the same
header then a "only once" pragma is a much cleaner solution.
[...]

The tricky part would be defining the semantics. Assuming that a
header is a file, consider systems where multiple files can have the
same name (if they're in different directories), and a single file can
have multiple names (links, symbolic links, mount points, etc.).

The simple answer is to use object equality for files rather than name
equality. A file is the same item if it is the same object.

One reasonable assumption is that features of the filesystem structure such as
links, symbolic links and mount points do not change during the compilation of
a program.

In practice, obtaining object quality for files may present problems to
implementors. What if the filesystem doesn't provide any kind of unique ID for
a file? Implementations may have to suffer along with some kind of
weaker equivalence based on names, such as using a canonicalized full path
name (path name to the object, with symlinks substituted for their targets)
or not even that.

This could be left as implementation-defined behavior, and a quality of
implementation issue.

C programs have to be contrived in order for mechanisms like pragma once to
break on name equivalence.

A simple C program that just uses portable header names like "foobar.h"
will not break.

A program which assumes that #include "../foobar.h" in one place the same thing
as #include "abc/foobar.h" is not highly portable; and it is contrived in such
a way as to break simple implementations of pragma once.

I think this is something that the compiler marketplace can sort out for
itself.
.



Relevant Pages

  • Re: Porting from VC6, Class Wizard Comments
    ... Either way #ifdef sequence, or #pragma once, it should be implied, the ... beyond (I never installed VS5 anywhere because it had so many other ... THe only place you currently need include guards is if you have a header ... I have always needed the #ifdef my header files! ...
    (microsoft.public.vc.mfc)
  • Re: Warning to newbies
    ... Richard, stay out of the discussion unless you can identify each ... guarantees that the code will compile on implementations other than the ... implementations that do provide such a header, ... Chop chop dickie. ...
    (comp.lang.c)
  • Re: Seperate compilation (header files n their implementations)
    ... > Since the main program includes the header files, ... > interfaces and not the implementations of the headers (since the ... > But the headers DON'T include their implementations; ... the code is validated by the compiler and translated ...
    (comp.lang.cpp)
  • Re: Best Practices: #include
    ... It does not require that the header file be included in every file; ... If the header file has been included once, in a given compilation, any subsequent ... the file not be included by #pragma once until it has been included one time, ... allows the header to be read where it's contents are unknown" is also content-free. ...
    (microsoft.public.vc.mfc)
  • Re: Best Practices: #include
    ... Specifies that the file, in which the pragma resides, will be included ... only once by the compiler in a build. ... This, then, presupposes that some one header will be #include'd in every ... >>dependencies (again to stdafx?). ...
    (microsoft.public.vc.mfc)