#include "..." with local sub folders

Discussion in 'C++' started by Marcel Müller, Dec 31, 2012.

  1. I have a folder structure like

    - src
    - core
    - core.cpp
    - core.h
    - gui
    - gui.cpp
    - gui.h
    - Makefile

    The question is how to write #include directives correctly.

    In core.cpp:
    #include "core.h"
    or
    #include "core/core.h"

    In gui.h:
    #include "../core/core.h"
    or
    #include "core/core.h"

    The compiler is always invoked from src. So the current directory from
    this point of view is src. But the current directory from the files is
    src/core or src/gui respectively. #include claims to search in the
    current directory first. But /which/ current directory?

    gcc seem to eat both. But I am unsure whether this is correct.
    None of these directories is in the include search path.


    Marcel
    Marcel Müller, Dec 31, 2012
    #1
    1. Advertising

  2. Marcel Müller

    Jorgen Grahn Guest

    On Mon, 2012-12-31, Paavo Helde wrote:
    > Marcel Müller <> wrote in news:50e163e5$0
    > $6581$-online.net:
    >
    >> I have a folder structure like
    >>
    >> - src
    >> - core
    >> - core.cpp
    >> - core.h
    >> - gui
    >> - gui.cpp
    >> - gui.h
    >> - Makefile
    >>
    >> The question is how to write #include directives correctly.
    >>
    >> In core.cpp:
    >> #include "core.h"
    >> or
    >> #include "core/core.h"
    >>
    >> In gui.h:
    >> #include "../core/core.h"
    >> or
    >> #include "core/core.h"
    >>

    ....
    > I would vote for:
    >
    > in core.cpp:
    > #include "core.h"


    Yes! No doubts about it -- it's the usual "I want the core.h which is
    close to myself" case and the existance of other directories is
    irrelevant.

    > In gui.h it depends if the gui subdir is considered a separate project or
    > not. In a separate project:
    >
    > #include <core/core.h>
    > (and add src on the include path when compiling the gui project).
    >
    > In one big project
    > #include "../core/core.h"
    > would also be fine (the code would be very tightly coupled anyway).
    >
    > This is a matter of taste though,


    For what it's worth, I would reason in exactly the same way.
    (Although I would try to avoid too much splitting into directories;
    the only thing I normally move out of the way is unit tests.)

    > I know people who frown upon any
    > occurence of ".." in the include lines.


    I remember hearing about such people decades ago, but cannot remember
    the rationale. It's not portable to non-Unix, non-Windows, but
    chances are the rest of your code isn't either.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jan 1, 2013
    #2
    1. Advertising

  3. Marcel Müller

    Öö Tiib Guest

    On Tuesday, 1 January 2013 19:28:51 UTC+2, Jorgen Grahn wrote:
    > On Mon, 2012-12-31, Paavo Helde wrote:
    > > I know people who frown upon any
    > > occurence of ".." in the include lines.

    >
    > I remember hearing about such people decades ago, but cannot remember
    > the rationale. It's not portable to non-Unix, non-Windows, but
    > chances are the rest of your code isn't either.


    One reason I have seen was because of limitations of tools/compiler. For
    example unit testing. It can be more convenient to provide fake core.h for
    gui.cpp that has #include "core/core.h" and it can be less convenient to
    provide it for #include "../core/core.h".

    On some case tricks like guitest.cpp that does #include "gui.cpp" might be
    needed to fool that "../core/core.h" to *not* include the actual core.h.
    Öö Tiib, Jan 1, 2013
    #3
  4. Marcel Müller <> wrote:
    > I have a folder structure like
    >
    > - src
    > - core
    > - core.cpp
    > - core.h
    > - gui
    > - gui.cpp
    > - gui.h
    > - Makefile
    >
    > The question is how to write #include directives correctly.
    >
    > In core.cpp:
    > #include "core.h"
    > or
    > #include "core/core.h"
    >
    > In gui.h:
    > #include "../core/core.h"
    > or
    > #include "core/core.h"
    >
    > The compiler is always invoked from src. So the current directory from
    > this point of view is src. But the current directory from the files is
    > src/core or src/gui respectively. #include claims to search in the
    > current directory first. But /which/ current directory?
    >
    > gcc seem to eat both. But I am unsure whether this is correct.
    > None of these directories is in the include search path.
    >
    >
    > Marcel


    My suggestion:

    #include "relative/path/from/current/file.h"
    (Use double quotes)

    #include <subpath/to/file.h>
    (Use angle brackets)
    And add the root directory to the include search path.

    There's still the question which of the two is appropriate, but independent
    of that it uses different syntax conventions for different usecases.

    I myself would use the first alternative inside a project and the second
    one for external dependencies.
    For subprojects I would say it depends.
    At least in header files I would prefer relative includes, just to be
    selfcontained. If that header is used in another project, it can be
    included without adding the additional directories to the search path.

    Tobi
    Tobias Müller, Jan 1, 2013
    #4
  5. On 02.01.13 00.43, Tobias Müller wrote:
    > My suggestion:
    >
    > #include "relative/path/from/current/file.h"
    > (Use double quotes)
    >
    > #include<subpath/to/file.h>
    > (Use angle brackets)
    > And add the root directory to the include search path.

    [...]
    > I myself would use the first alternative inside a project and the second
    > one for external dependencies.


    This is exacly the way I go. But one project does no longer reasonably
    fit into one folder (about 100 files). At least it is inconvenient in
    Eclipse's Project Explorer.

    > At least in header files I would prefer relative includes, just to be
    > selfcontained.


    ACK. (As long as we talk about public header files.)

    > If that header is used in another project, it can be
    > included without adding the additional directories to the search path.


    This seems to work with "" too. But I dislike this kind of dependencies.


    Marcel
    Marcel Müller, Jan 7, 2013
    #5
  6. Marcel Müller <> wrote:
    >> If that header is used in another project, it can be
    >> included without adding the additional directories to the search path.

    >
    > This seems to work with "" too. But I dislike this kind of dependencies.


    "..." is strictly more powerful than <...>. "..." does everything that
    <...> does and additionally also resolves relative paths.

    That's why I suggest that you use "..." _only_ for relative paths, and
    <...> for lookup in the include directories. Just to make the intent clear.

    Tobi
    Tobias Müller, Jan 7, 2013
    #6
  7. On 1/7/13 3:34 PM, Tobias Müller wrote:
    > Marcel Müller <> wrote:
    >>> If that header is used in another project, it can be
    >>> included without adding the additional directories to the search path.

    >>
    >> This seems to work with "" too. But I dislike this kind of dependencies.

    >
    > "..." is strictly more powerful than <...>. "..." does everything that
    > <...> does and additionally also resolves relative paths.
    >
    > That's why I suggest that you use "..." _only_ for relative paths, and
    > <...> for lookup in the include directories. Just to make the intent clear.
    >
    > Tobi
    >


    While the wording of the standard just defines that both use an
    "implementation defined" method of determining were to look, and that
    "..." will fall back to the method used for <...> if it otherwise files,
    the generally accepted practice is that <...> is for "system" files and
    "..." is for user files, and some implementations may not allow the user
    to add header files to the list that <...> will look for.

    My preference is to use <...> to indicate that the header is something
    "standard" (either the C/C++ standard, operating system, other headers
    provided by the implementation or major 3rd party libraries available to
    most applications in the system, and "..." for application specific
    header files, or locally developed specific libraries. (There can be a
    grey area between these that I need to decide on a case by case basis).

    This allows me to know, at least somewhat, where to look for the
    documentation of the header.

    It is a gcc specification that (as part of its "implementation defined"
    choices) that "..." includes the "current directory", but <...> doesn't.
    Richard Damon, Jan 8, 2013
    #7
  8. Tobias Müller wrote:

    > Marcel Müller <> wrote:
    >>> If that header is used in another project, it can be
    >>> included without adding the additional directories to the search path.

    >>
    >> This seems to work with "" too. But I dislike this kind of dependencies.

    >
    > "..." is strictly more powerful than <...>. "..." does everything that
    > <...> does and additionally also resolves relative paths.


    Not sure whether this is what you meant, but both GCC and VC++ also
    resolve relative paths within <...>. They apply them relative to the
    configured (and default) include path elements.

    The difference to "..." is that before applying the relative path to the
    compiler include path, it is applied to the directory of the current
    file.

    Gerhard
    Gerhard Fiedler, Jan 9, 2013
    #8
  9. Gerhard Fiedler <> wrote:
    > Not sure whether this is what you meant, but both GCC and VC++ also
    > resolve relative paths within <...>. They apply them relative to the
    > configured (and default) include path elements.
    >
    > The difference to "..." is that before applying the relative path to the
    > compiler include path, it is applied to the directory of the current
    > file.


    Yes that's what I wanted to say. Sorry for the confusion.

    And with the usual path resolving algorithms, we can even say resolving is
    applied to the path of the current file itself. That makes it consistent
    with e.g. relative URIs in XML or HTML.

    Tobi
    Tobias Müller, Jan 9, 2013
    #9
    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. =?Utf-8?B?RGVhc3Vu?=
    Replies:
    1
    Views:
    342
    Karl Seguin
    Jul 12, 2005
  2. Ben
    Replies:
    2
    Views:
    865
  3. =?Utf-8?B?RGF2aWQgTG96emk=?=

    URL Rewriting and sub folders

    =?Utf-8?B?RGF2aWQgTG96emk=?=, Oct 26, 2007, in forum: ASP .Net
    Replies:
    0
    Views:
    346
    =?Utf-8?B?RGF2aWQgTG96emk=?=
    Oct 26, 2007
  4. Andreas Bogenberger
    Replies:
    3
    Views:
    886
    Andreas Bogenberger
    Feb 22, 2008
  5. Lawrence D'Oliveiro

    Death To Sub-Sub-Sub-Directories!

    Lawrence D'Oliveiro, May 5, 2011, in forum: Java
    Replies:
    92
    Views:
    1,975
    Lawrence D'Oliveiro
    May 20, 2011
Loading...

Share This Page