Home/ Questions/Q 139089
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T07:22:22+00:00

I’ve reviewed questions How to use include directive correctly and C++ #include semantics and

  • 0

I’ve reviewed questions How to use include directive correctly and C++ #include semantics and neither addresses this – nor do the others suggested by SO when I typed the title…

What, if any, are the benefits of writing:

#include '../include/someheader.h' #include '../otherdir/another.h'

compared with using just a plain file name:

#include 'someheader.h' #include 'another.h'

or perhaps a relative name without the ‘..‘:

#include 'include/someheader.h' #include 'otherdir/another.h'

The problems I see are:

  • You can’t move a header without worrying about which source files include it.
  • You can end up with very long paths for headers in dependencies and error reports. I had one today with ‘../dir1/include/../../include/../dir2/../include/header.h‘.

The only merit I can see is that while you do not need to move files around, you might be able to get away without always using ‘-I‘ directives to find headers, but the loss of flexibility, and the complexity of compiling in sub-sub-directories, etc seems to outweigh the benefit.

So, am I overlooking a benefit?

Thanks for the inputs. I think the consensus is that there aren’t any major benefits to the notation using ‘..’ that I’m overlooking. In general terms, I like the ‘somewhere/header.h’ notation; I do use it in new projects. The one I’m working on is anything but new.

One of the problems is that there are various sets of headers, often with a prefix such as rspqr.h, rsabc.h, rsdef.h, rsxyz.h. These are all related to code in the rsmp directory, but some of the headers are in rsmp and others are in the central include directory, which does not have sub-directories such as rsmp in it. (And repeat for the various other areas of the code; there are headers in multiple locations, needed randomly by other bits of code.) Moving stuff around is a major problem because the code has gotten so convoluted over the years. And the makefiles are not consistent in which -I options are provided. All in all, it is a sad story of not-so-benign neglect over a period of decades. Fixing it all without breaking anything is going to be a long, tedious job.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. I prefer the path syntax as it makes it very clear what namespace or module the header file belongs to.

    #include 'Physics/Solver.h'

    Is very self-describing without requiring every module to prefix their name to header files.

    I almost never use the ‘..’ syntax though, instead I have my project includes specify the correct base locations.

    • 0