Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > #include "..." with local sub folders

Reply
Thread Tools

#include "..." with local sub folders

 
 
Marcel Müller
Guest
Posts: n/a
 
      12-31-2012
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
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-01-2013
On Mon, 2012-12-31, Paavo Helde wrote:
> Marcel Müller <(E-Mail Removed)> wrote in news:50e163e5$0
> $6581$(E-Mail Removed)-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 .
 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      01-01-2013
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.
 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      01-01-2013
Marcel Müller <(E-Mail Removed)> 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
 
Reply With Quote
 
Marcel Müller
Guest
Posts: n/a
 
      01-07-2013
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
 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      01-07-2013
Marcel Müller <(E-Mail Removed)> 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
 
Reply With Quote
 
Richard Damon
Guest
Posts: n/a
 
      01-08-2013
On 1/7/13 3:34 PM, Tobias Müller wrote:
> Marcel Müller <(E-Mail Removed)> 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.
 
Reply With Quote
 
Gerhard Fiedler
Guest
Posts: n/a
 
      01-09-2013
Tobias Müller wrote:

> Marcel Müller <(E-Mail Removed)> 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
 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      01-09-2013
Gerhard Fiedler <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Death To Sub-Sub-Sub-Directories! Lawrence D'Oliveiro Java 92 05-20-2011 06:50 AM
zipping files folders and sub folders w/ winzip or winrar Mike Computer Support 5 03-28-2008 09:10 PM
Recognising Sub-Items and sub-sub items using xslt Ben XML 2 09-19-2007 09:35 AM
Desktop accesses laptop and reads folders but Laptop only accesses/opens Desktop but cannot read folders, access is denied onclejon Wireless Networking 3 11-01-2006 10:50 PM
Syncing POP folders with IMAP folders Rich Computer Support 1 02-12-2004 09:36 PM



Advertisments