Jesper Wolf Jespersen wrote:
> Faktisk er forskellen at man ved angivelse af "" omkring filnavnet lader 
> compileren søge i current directory før den leder i include pathen.
> Angiver man <> omkring filnavnet er det kun include pathen der bruges.
> 
> Hvis man har current directory med først i sin include path er der ingen 
> forskel mellem de to.
> 
> Jeg bruger "" notationen til lokale include filer og <> til systemfiler, den 
> konvention er der mange der følger.
Jeg tror faktisk at den præcise forskel er compiler specifik.
GCC
http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Search-Path.html
som siger (for en Unix platform):
<> form:
-I dirs
/usr/local/include
/usr/lib/gcc-lib/target/version/include
/usr/target/include
/usr/include
"" form:
dir including file (ikke nødvendigvis current dir)
-I dirs
/usr/local/include
/usr/lib/gcc-lib/target/version/include
/usr/target/include
/usr/include
DEC C for en VMS platform siger (undskyld det lange citat):
      For the quoted form, the search order is:
      1.  One of the following:
           o  If /NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE (the default) is
              in effect, search the directory containing the file in
              which the #include directive itself occurred.  The meaning
              of "directory containing" is:  the RMS "resultant string"
              obtained when the file in which the #include occurred was
              opened, except that the filename and subsequent components
              are replaced by the default file type for headers (".H", or
              just "." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect).
              The "resultant string" will not have translated any
              concealed device logical.
           o  If /NESTED_INCLUDE_DIRECTORY=PRIMARY_FILE is in effect,
              search the default file type for headers using the context
              of the primary source file.  This means that just the file
              type (".H" or ".") is used for the default file-spec but,
              in addition, the chain of "related file-specs" used to
              maintain the sticky defaults for processing the next
              top-level source file is applied when searching for the
              include file.
           o  If /NESTED_INCLUDE_DIRECTORY=NONE is in effect, this entire
              step (Step 1) is bypassed.
      2.  Search the places specified in the /INCLUDE_DIRECTORY
          qualifier, if any.  A place that can be parsed successfuly as
          an OpenVMS file-spec and that does not contain an explicit file
          type or version specification is edited to append the default
          header file type specification (".H" or ".").
          A place containing a "/" character is considered to be a
          UNIX-style name.  If the name in the #include directive also
          contains a "/" character that is not the first character and is
          not preceded by a "!" character (that is, it is not an absolute
          UNIX-style pathname), then the name in the #include directive
          is appended to the named place, separated by a "/" character,
          before applying the decc$to_vms pathname translation function.
      3.  If "DECC$USER_INCLUDE" is defined as a logical name, search
          "DECC$USER_INCLUDE:.H", or just "DECC$USER_INCLUDE:." if
          /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.
      4.  If the file is not found, follow the steps for the
          angle-bracketed form of inclusion.
      For the angle-bracketed form, the search order is:
      1.  Search the place "/".  This is a UNIX-style name that can
          combine only with UNIX names specified explicitly in the
          #include directive.  It causes a specification like
          <sys/types.h> to be considered first as /sys/types.h, which is
          translated to SYS:TYPES.H.
      2.  Search the places specified in the /INCLUDE_DIRECTORY
          qualifier, exactly as in Step 2 for the quoted form of
          inclusion.
      3.  If "DECC$SYSTEM_INCLUDE" is defined as a logical name, search
          "DECC$SYSTEM_INCLUDE:.H", or just "DECC$SYSTEM_INCLUDE:." if
          /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.
      4.  If "DECC$LIBRARY_INCLUDE" is defined as a logical name and
          "DECC$SYSTEM_INCLUDE" is NOT defined as a logical name, search
          "DECC$LIBRARY_INCLUDE:.H", or just "DECC$LIBRARY_INCLUDE:." if
          /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.
      5.  If neither "DECC$LIBRARY_INCLUDE" nor "DECC$SYSTEM_INCLUDE" are
          defined as logical names, then search the default list of
          places for plain text-file copies of compiler header files as
          follows:
          SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF].H
          SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C].H
          If the file is not found, perform the text library search
          described in the next step.
      6.  Extract the simple filename and file type from the #include
          specification and use the filename as the module name to search
          a list of text libraries associated with that file type.
          For any file type, the initial text libraries searched consist
          of those named on the command line with /LIBRARY qualifiers.
          If the /INCLUDE_DIRECTORY qualifier contained an empty string,
          no further text libraries are searched.  Otherwise,
          DECC$TEXT_LIBRARY is searched for all file types.
          If "DECC$LIBRARY_INCLUDE" is defined as a logical name, then no
          further text libraries are searched.  Otherwise, the subsequent
          libraries searched for each file type are:
               For ".H" or ".":
                 SYS$LIBRARY:DECC$RTLDEF.TLB
                 SYS$LIBRARY:SYS$STARLET_C.TLB
               For any file type other then ".H" or ".":
                 SYS$LIBRARY:SYS$STARLET_C.TLB
      7.  If the previous step fails, search:
          SYS$LIBRARY:.H
          Under /ASSUME=NOHEADER_TYPE_DEFAULT, the default file type is
          modified as usual.
Arne