include paths - is there a defacto standard?

Discussion in 'C++' started by Ole Nielsby, Nov 4, 2007.

  1. Ole Nielsby

    Ole Nielsby Guest

    The standard doesn't define this but what conventions do projects use?

    As I understand it,

    #include <somelibrary.h>

    is used for including system headers and those of frameworks such
    as wxWidgets - and

    #include "someheader.h"

    is used for more application-specific things.

    The VC8 docs say, #include <...> searches the paths set for the
    project, but #include "..." tries the dir of the file with the include,
    and the file that included it etc... before it searches the project
    setting include paths.

    Is this a defacto standard, or do compilers implement different
    ways of doing it? Is there a sort of minimal conventions programmers
    stick to to be compiler-independent?
     
    Ole Nielsby, Nov 4, 2007
    #1
    1. Advertising

  2. "Ole Nielsby" <> wrote in
    message news:472db0b0$0$2098$...
    : The standard doesn't define this but what conventions do projects use?
    :
    : As I understand it,
    :
    : #include <somelibrary.h>
    :
    : is used for including system headers and those of frameworks such
    : as wxWidgets - and
    :
    : #include "someheader.h"
    :
    : is used for more application-specific things.
    :
    : The VC8 docs say, #include <...> searches the paths set for the
    : project, but #include "..." tries the dir of the file with the
    include,
    : and the file that included it etc... before it searches the project
    : setting include paths.
    :
    : Is this a defacto standard, or do compilers implement different
    : ways of doing it? Is there a sort of minimal conventions programmers
    : stick to to be compiler-independent?

    The only thing defined in the standard is that "..." first searches
    for a file in some (user-defined) locations and then, if not successful,
    searches the same locations as for <...>.

    In practice, most compilers I know handle "..." in a similar fashion
    as VC8: looking for paths relative to the currently processed file.
    But there is no guarantee that other compilers will do the same.

    I knew some projects/guidelines that required exclusive use of <...>
    and proper specification of search paths in compiler invocation.

    I personally use <...> for all 'absolute' files/paths referring to
    (usually external) libraries, and "..." for (relative path) references
    to files within the same module.

    I think that this can be left as a stylistic choice...


    --
    http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
    Brainbench MVP for C++ <> http://www.brainbench.com
     
    Ivan Vecerina, Nov 4, 2007
    #2
    1. Advertising

  3. Ole Nielsby

    James Kanze Guest

    On Nov 4, 12:44 pm, "Ole Nielsby"
    <> wrote:
    > The standard doesn't define this but what conventions do projects use?


    > As I understand it,


    > #include <somelibrary.h>


    > is used for including system headers and those of frameworks such
    > as wxWidgets - and


    > #include "someheader.h"


    > is used for more application-specific things.


    > The VC8 docs say, #include <...> searches the paths set for the
    > project, but #include "..." tries the dir of the file with the include,
    > and the file that included it etc... before it searches the project
    > setting include paths.


    > Is this a defacto standard, or do compilers implement different
    > ways of doing it?


    It seems pretty much the usual convention. I'm not sure that
    other compilers try the directories of all of the including
    files, however: most of the time, I think, it is the directory
    of the file which does the include, then treat it like a <...>.
    All of the compilers I know apply the /I or -I options to the
    <...> (and thus implicitly to the "...", since the "..." uses
    the <...> paths if it doesn't find the code locally). I think
    some compilers have additional options which only apply to the
    "..." form, as well. And of course, the only thing the standard
    really says is that if the search with the "..." form fails, the
    compiler should retry as if it were specified <...>.

    > Is there a sort of minimal conventions programmers stick to to
    > be compiler-independent?


    The usual convention seems to work well in practice: system
    headers, and anything you assimulate to system headers, use
    <...>, other headers use "...". You'll probably find some
    variation as to what is assimulated to system headers, however:
    some places will include not only third party libraries, like
    wxWidgets, but also lower level in house libraries which are
    used in many different projects, where as others may not even
    consider major third party libraries, limiting <...> to those
    libraries furnished with the compiler or bundled with the OS.

    In general, I wouldn't worry about it too much, except to ensure
    that local headers use "...".

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 4, 2007
    #3
  4. Ole Nielsby

    Guest

    On Nov 4, 12:57 pm, James Kanze <> wrote:
    > On Nov 4, 12:44 pm, "Ole Nielsby"
    >
    > <> wrote:
    > > The standard doesn't define this but what conventions do projects use?
    > > As I understand it,
    > > #include <somelibrary.h>
    > > is used for including system headers and those of frameworks such
    > > as wxWidgets - and
    > > #include "someheader.h"
    > > is used for more application-specific things.
    > > The VC8 docs say, #include <...> searches the paths set for the
    > > project, but #include "..." tries the dir of the file with the include,
    > > and the file that included it etc... before it searches the project
    > > setting include paths.
    > > Is this a defacto standard, or do compilers implement different
    > > ways of doing it?

    >
    > It seems pretty much the usual convention. I'm not sure that
    > other compilers try the directories of all of the including
    > files, however: most of the time, I think, it is the directory
    > of the file which does the include, then treat it like a <...>.
    > All of the compilers I know apply the /I or -I options to the
    > <...> (and thus implicitly to the "...", since the "..." uses
    > the <...> paths if it doesn't find the code locally). I think
    > some compilers have additional options which only apply to the
    > "..." form, as well. And of course, the only thing the standard
    > really says is that if the search with the "..." form fails, the
    > compiler should retry as if it were specified <...>.
    >
    > > Is there a sort of minimal conventions programmers stick to to
    > > be compiler-independent?

    >
    > The usual convention seems to work well in practice: system
    > headers, and anything you assimulate to system headers, use
    > <...>, other headers use "...". You'll probably find some
    > variation as to what is assimulated to system headers, however:
    > some places will include not only third party libraries, like
    > wxWidgets, but also lower level in house libraries which are
    > used in many different projects, where as others may not even
    > consider major third party libraries, limiting <...> to those
    > libraries furnished with the compiler or bundled with the OS.
    >
    > In general, I wouldn't worry about it too much, except to ensure
    > that local headers use "...".
    >
    > --
    > James Kanze (GABI Software) email:
    > Conseils en informatique orientée objet/
    > Beratung in objektorientierter Datenverarbeitung
    > 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


    Correct me if I am wrong. My understanding is that <...> will include
    the system defined path. "..." will search the user defined path where
    you use -I to specify if you are using UNIX.
     
    , Nov 5, 2007
    #4
  5. Ole Nielsby

    Andre Kostur Guest

    "" <> wrote in
    news::

    >
    > Correct me if I am wrong. My understanding is that <...> will include
    > the system defined path. "..." will search the user defined path where
    > you use -I to specify if you are using UNIX.


    All of the compilers that I've used will apply the -I directories to both
    <> and "" includes.
     
    Andre Kostur, Nov 5, 2007
    #5
  6. * Andre Kostur:
    > "" <> wrote in
    > news::
    >
    >> Correct me if I am wrong. My understanding is that <...> will include
    >> the system defined path. "..." will search the user defined path where
    >> you use -I to specify if you are using UNIX.

    >
    > All of the compilers that I've used will apply the -I directories to both
    > <> and "" includes.


    Don't know if it has been mentioned, but the standard's guarantee is
    that "..." applies some extra initial searching, then if that fails
    applies the same search as <...>. The initial extra search for "..." is
    unspecified but typically in the directory of the including file. ++,
    depending on the compiler etc.

    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Nov 5, 2007
    #6
  7. Ole Nielsby

    James Kanze Guest

    On Nov 5, 7:46 pm, "Alf P. Steinbach" <> wrote:
    > * Andre Kostur:


    > > "" <> wrote in
    > >news::


    > >> Correct me if I am wrong. My understanding is that <...>
    > >> will include the system defined path. "..." will search the
    > >> user defined path where you use -I to specify if you are
    > >> using UNIX.


    > > All of the compilers that I've used will apply the -I
    > > directories to both <> and "" includes.


    > Don't know if it has been mentioned, but the standard's
    > guarantee is that "..." applies some extra initial searching,
    > then if that fails applies the same search as <...>. The
    > initial extra search for "..." is unspecified but typically in
    > the directory of the including file. ++, depending on the
    > compiler etc.


    I mentionned it, but it certainly bears repeating: if <...> will
    find the file, so will "...". (G++ has a deprecated option
    which will violate this rule---don't use it. IIRC, g++ used to
    have an option which only affected "...", but I can't find it
    anywhere in the documentation; perhaps I'm confusing it with
    another compiler.)

    I might add that when generating dependencies, g++ has an option
    to only consider the files included by "..." in the generated
    dependencies. This sounds like the basis of a good rule to me:
    use "..." if you want the file to be considered in the
    dependencies, <...> if you don't. (You typically don't want the
    system headers in your dependency checking, since this
    significantly increases make times for nothing.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 6, 2007
    #7
  8. Ole Nielsby

    Ben Pfaff Guest

    James Kanze <> writes:

    > I might add that when generating dependencies, g++ has an option
    > to only consider the files included by "..." in the generated
    > dependencies.


    I believe that you are mistaken, for recent versions of GCC.
    From the GCC 4.1 manual:

    `-MM'
    Like `-M' but do not mention header files that are found in system
    header directories, nor header files that are included, directly
    or indirectly, from such a header.

    This implies that the choice of angle brackets or double quotes in
    an `#include' directive does not in itself determine whether that
    header will appear in `-MM' dependency output. This is a slight
    change in semantics from GCC versions 3.0 and earlier.

    (GCC 3.0 is 6 years old.)
    --
    Ben Pfaff
    http://benpfaff.org
     
    Ben Pfaff, Nov 6, 2007
    #8
  9. Ole Nielsby

    James Kanze Guest

    On Nov 7, 12:03 am, Ben Pfaff <> wrote:
    > James Kanze <> writes:
    > > I might add that when generating dependencies, g++ has an option
    > > to only consider the files included by "..." in the generated
    > > dependencies.


    > I believe that you are mistaken, for recent versions of GCC.
    > From the GCC 4.1 manual:


    > `-MM'
    > Like `-M' but do not mention header files that are found in system
    > header directories, nor header files that are included, directly
    > or indirectly, from such a header.


    > This implies that the choice of angle brackets or double quotes in
    > an `#include' directive does not in itself determine whether that
    > header will appear in `-MM' dependency output. This is a slight
    > change in semantics from GCC versions 3.0 and earlier.


    So it would seem. I was looking at two different versions of
    g++ when I wrote this: the latest, but also 2.95.3 (trying to
    find the option to add a directory to the path only for <...>,
    which I thought was there at one time), and apparently got
    confused about them.

    IMHO, this is a step backwards, since it no longer allows the
    project to define what it considers "system". In addition to
    the standard headers, for example, we use Posix, Sybase and
    Reuteurs (and maybe some other stuff I'm not aware of).
    Conceptually, they're all "system" for us, and it would be
    preferable not to consider them when generating dependencies.
    Presumable, g++ doesn't consider the Posix headers (which are in
    /usr/include), but would consider the Sybase and Reuteurs
    headers (which are all somewhere under /tools in our
    systems)---and if the installation installed the Sybase and
    Reuteurs headers under /usr/include, g++ would act differently.
    (What about /usr/local/include? I have the impression that a
    lot of Linux system software installs its headers there. And a
    lot of Linux non-system software installs them under
    /usr/include.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 7, 2007
    #9
  10. Ole Nielsby

    mojmir Guest

    On Nov 4, 9:57 pm, James Kanze <> wrote:

    > The usual convention seems to work well in practice: system
    > headers, and anything you assimulate to system headers, use
    > <...>, other headers use "...".
    > ...
    > In general, I wouldn't worry about it too much, except to ensure
    > that local headers use "...".


    What about order of includes? I met cases where the inclusion
    order was important so that the user had to be very careful.

    Is there any general advice like
    1. inclusion of system headers
    2. inclusion of standard library headers
    3. inclusion of framework headers
    4. inclusion of local headers
    etc.?

    Thanks,
    Mojmir
     
    mojmir, Nov 8, 2007
    #10
  11. Ole Nielsby

    Jim Langston Guest

    "mojmir" <> wrote in message
    news:...
    > On Nov 4, 9:57 pm, James Kanze <> wrote:
    >
    >> The usual convention seems to work well in practice: system
    >> headers, and anything you assimulate to system headers, use
    >> <...>, other headers use "...".
    >> ...
    >> In general, I wouldn't worry about it too much, except to ensure
    >> that local headers use "...".

    >
    > What about order of includes? I met cases where the inclusion
    > order was important so that the user had to be very careful.
    >
    > Is there any general advice like
    > 1. inclusion of system headers
    > 2. inclusion of standard library headers
    > 3. inclusion of framework headers
    > 4. inclusion of local headers
    > etc.?
    >
    > Thanks,
    > Mojmir


    Personally, that's pretty much the way I always do it. I include the system
    headers at the top, any 3rd party headers under those, and my headers at hte
    bottom.

    As for system headers/standard library headers, I tend to put stl headers at
    the top.
     
    Jim Langston, Nov 8, 2007
    #11
  12. Ole Nielsby

    James Kanze Guest

    On Nov 8, 8:54 am, "Jim Langston" <> wrote:
    > "mojmir" <> wrote in message


    > news:...
    > > On Nov 4, 9:57 pm, James Kanze <> wrote:


    > >> The usual convention seems to work well in practice: system
    > >> headers, and anything you assimulate to system headers, use
    > >> <...>, other headers use "...".
    > >> ...
    > >> In general, I wouldn't worry about it too much, except to ensure
    > >> that local headers use "...".


    > > What about order of includes? I met cases where the inclusion
    > > order was important so that the user had to be very careful.


    > > Is there any general advice like
    > > 1. inclusion of system headers
    > > 2. inclusion of standard library headers
    > > 3. inclusion of framework headers
    > > 4. inclusion of local headers
    > > etc.?


    > Personally, that's pretty much the way I always do it. I
    > include the system headers at the top, any 3rd party headers
    > under those, and my headers at hte bottom.


    There is one important exception. In the .cc files which
    implement a specific header, that header should always be
    included first.

    > As for system headers/standard library headers, I tend to put
    > stl headers at the top.


    I tend to put each group in alphabetical order (simply because
    it's the easiest order to automate.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 8, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Noah
    Replies:
    5
    Views:
    814
  2. user923005

    Re: Defacto standard string library

    user923005, Dec 29, 2008, in forum: C Programming
    Replies:
    3
    Views:
    272
    user923005
    Dec 29, 2008
  3. Stephen Sprunk

    Re: Defacto standard string library

    Stephen Sprunk, Dec 30, 2008, in forum: C Programming
    Replies:
    6
    Views:
    304
    Keith Thompson
    Jan 2, 2009
  4. Phil Carmody

    Re: Defacto standard string library

    Phil Carmody, Jan 1, 2009, in forum: C Programming
    Replies:
    59
    Views:
    1,158
    Richard Tobin
    Jan 5, 2009
  5. Ilias Lazaridis
    Replies:
    9
    Views:
    116
    Michele Dondi
    Jun 23, 2007
Loading...

Share This Page