#include "..." with local sub folders

[Marcel Müller]

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

[Paavo Helde]

Marcel Müller <news.5...@spamgourmet.org> wrote in news:50e163e5$0
$6581$9b4e...@newsspool3.arcor-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"
>
> 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?

This is all implementation-defined, so you would need to consult your
compiler documentation. However, many compilers (including gcc) search
the directory of the .cpp first. If it looks like the current working
directory of the compiler process also works, then this is most probably
only because a Makefile or equivalent has added a -I. option somewhere.
But as said, this is all implementation-defined, MSVC for example also
searches in a number of "previously found" include file directories,
hoping for a good luck in a true MS fashion.

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

I would vote for:

in core.cpp:
#include "core.h"

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, I know people who frown upon any
occurence of ".." in the include lines.

Cheers
Paavo

[Robert Wessel]

On Mon, 31 Dec 2012 05:29:50 -0600, Paavo Helde
<myfir...@osa.pri.ee> wrote:

>Marcel M�ller <news.5...@spamgourmet.org> wrote in news:50e163e5$0

Not quite luck, but a quoted include will look in the directory in
which the source file containing the include was found, and that of
any containing source files if the includes are nested.

But odd choices are hardly limited to MSVC, why, for example, would we
actually want /usr/local/include/ and /usr/include/ as defaults in
GCC?

[Jorgen Grahn]

On Mon, 2012-12-31, Paavo Helde wrote:
> Marcel Müller <news.5...@spamgourmet.org> wrote in news:50e163e5$0
> $6581$9b4e...@newsspool3.arcor-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 .

[Öö Tiib]

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.

[Tobias Müller]

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

[Marcel Müller]

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

[Tobias Müller]

Marcel Müller <news.5...@spamgourmet.org> 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

[Richard Damon]

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.

[Gerhard Fiedler]

Tobias M�ller wrote:

> Marcel M�ller <news.5...@spamgourmet.org> 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

[Tobias Müller]

Gerhard Fiedler <gel...@gmail.com> 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