Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-07-28 21:02:11


From: Beman Dawes <beman_at_[hidden]>
> At 07:03 PM 7/28/99 -0600, Greg Colvin wrote:
>
> >> Hum... This might be a problem in theory, but in practice are there
> >> really any compilers out there that would prevent (2)? Anyone know
> >> of a real-world compiler with either of these limitations?
> >
> >I don't know about the real world (:-) but the standard seems to
> >say you should use the "name" form for including files.
>
> I have read paragraphs 2 and 3 several times and can't see any
> difference, other that the ordering of sentances and "..." falling
> back to <...>. Oddly enough, the only problem I ever had with a real
> compiler was with "..." although that was clearly a compiler bug.
>
> What are you seeing that I am missing?

Not much, that's why I said "seems to". We took these paragraphs
verbatim from the C standard, and the rational says, in effect,
"we wanted to say what these mean but couldn't" so its all pretty
much implementation defined. I had thought that the intent was
that:
   <name> forms were intended for standard and system C++ headers;
   <name.h> forms were intended for standard and system C headers;
   "whatever" forms were intended for user source files;
where "headers" need not be files at all.

In the real world the main difference is how and where to search.

So for GCC we have:

   -Idir
   Add the directory dir to the head of the list of directories to be
   searched for header files. This can be used to override a system
   header file, substituting your own version, since these
   directories are searched before the system header file
   directories. If you use more than one `-I' option, the directories
   are scanned in left-to-right order; the standard system
   directories come after.

   -I-
   Any directories you specify with `-I' options before the `-I-'
   option are searched only for the case of `#include "file"'; they
   are not searched for `#include <file>'. If additional directories
   are specified with `-I' options after the `-I-', these directories
   are searched for all `#include' directives. (Ordinarily all `-I'
   directories are used this way.) In addition, the `-I-' option
   inhibits the use of the current directory (where the current input
   file came from) as the first search directory for `#include
   "file"'. There is no way to override this effect of `-I-'. With
   `-I.' you can specify searching the directory which was current when
   the compiler was invoked. That is not exactly the same as what the
   preprocessor does by default, but it is often satisfactory. `-I-'
   does not inhibit the use of the standard system directories for
   header files. Thus, `-I-' and `-nostdinc' are independent.

And for VC++ we have:

   #include "path-spec"

   #include <path-spec>

   The path-spec is a filename optionally preceded by a directory
   specification. The filename must name an existing file. The syntax of
   the path-spec depends on the operating system on which the program is
   compiled.

   Both syntax forms cause replacement of that directive by the entire
   contents of the specified include file. The difference between the two
   forms is the order in which the preprocessor searches for header files
   when the path is incompletely specified.
 
   Quoted form
      This form instructs the preprocessor to look for include files in the
      same directory of the file that contains the #include statement, and
      then in the directories of whatever files that include (#include) that
      file. The preprocessor then searches along the path specified by the /I
      compiler option, then along paths specified by the INCLUDE environment
      variable.
 
   Angle-bracket form
      This form instructs the preprocessor to search for include files first
      along the path specified by the /I compiler option, then along the path
      specified by the INCLUDE environment variable.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk