Re: what's the different between #incldue " xxx" and #include <xxx >

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

On Tue, 07 Jun 2005 09:11:55 +0200, Roland Frank wrote:

> Hi boki,
>
> although the previous posters quite correctly explained
> what difference it makes with VC++ to use the "" or <> form
> of the #include directive, they completely fail to explain
> WHY there are two different forms in the first place.
> This all originates in the C++ standard.
> The "" version dates all back to the days C was invented
> and means in short "include the given files here" using an
> implementation defined search sequence for the file name
> between the "".
> The <> version is quite different. Avoiding the legalese of
> the standard it means that the char sequence between the
> brackets does NOT necessarily denote a file name. It says
> that it "uniquely identifies a header" in a implementation
> defined way. This could for example mean that the identifier
> between <> is an index into a database and the header fetched
> from there.

The same thing applies to the "" form; compilers fall back on the <> form
if the "" form fails or simply isn't supported.

> I think the rationale behind this was, that on some operation
> system it might be illegal to use filenames without extensions
> or that there might be a restriction in the length of filenames.
> For example #include <exception> might be an illegal filename
> (it is on DOS). The creators of the standard wanted to make shure
> that a program that includes the headers as defined in the standard
> to correctly compile on all platforms without changes. So, a DOS
> compiler could lookup the <exception> in the example in a file,
> find the filename "exceptio.hhh" and then use this filename instead.

Correct. The compiler can map names in #include directives directly to
physical filenames, indirectly by performing some transformation on the
filename (e.g. translating path separators), to arrays of text representing
the header contents stored in the compiler itself, etc.

> VC++ implementation of the <> is completely conforming to the
> standard but I wouldn't use the <> form for anything else but
> the headers of the standard library, as you might be in for a
> big surprise if you switch compilers and use the <> as simply
> a means for including files with a different search sequence.

You might also be in for a big surprise if you use the "" form for third
party library headers that don't use sufficiently unique names. That's also
true for the <> form, but at least you don't have to worry about choosing
globally unique names for the headers you create yourself. (Macro guards
are another story, of course!) Again, this is all implementation-defined,
but the implementation I've seen most commonly is what I described in my
earlier message, with "" to refer to files located relative to the file
making the #include, and <> for everything else. It's the most sensible
approach to take; for example, gcc does it this way, too:

http://www.ugcs.caltech.edu/info/gcc/cpp_2.html#SEC8

As does Sun:

http://docs.sun.com/source/819-0494/sun.specific.html#pgfId-1004269

To minimize the danger of conflicting filenames, apply the approach I
described in my earlier message.

--
Doug Harrison
Microsoft MVP - Visual C++
.

Relevant Pages

  • Re: Preprocessor and sizeof()
    ... coming from a compiler vendor baffled me even more. ... "standard", i.e. poor) ... its headers and libraries, and in some cases is required to, as some ... into an issue with one such case, namely the offsetof macro. ...
    (comp.lang.c)
  • Re: Header Files and Interfaces Yet Again
    ... >> Standard, I will have to adjust my headers to match the implementation. ... I can use the declarations in the headers to compile my ... > I do not that much about compiler design as to asses whether this is ...
    (comp.lang.cpp)
  • Re: -POWDER- How the hell do I compile this?
    ... with it because other standard headers included the forgotten headers ... The compiler writers for taking the easy road and including ... not going to look up the iostream spec to verify this is intentional ...
    (rec.games.roguelike.misc)
  • Re: #include "file" -vs- #include <file>
    ... > about what actually happens is specific to your compiler. ... > are reserved for the compiler headers. ... > necessarily so, and even if it is so in the Standard, all compilers I've ... know of, but even if is a file, these two directives are ...
    (comp.lang.cpp)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)