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