#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

 

[Jorgen Grahn]

....
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

 

[Öö Tiib]

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.

 

[Tobias 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

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]

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]

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]

"..." 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.

 

[Gerhard Fiedler]

"..." 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]

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