0
#include ("/" "include/foo.h")
#include ("/" "include/bar.h")

I.e., I have gotten things like.. char* a = "/" "include/foo.h"; to work. So I'm wondering, why not add this as a feature for the preprocessor to?

Or maybe.. are there any preprocessors that support this syntax?

My thinking is that you could do something like..

// config.h

#define LIB1_PATH "/include"

and then..

// main.c

#include "config.h"
#include (LIB1_PATH "foo.h")
#include (LIB1_PATH "bar.h")

If you then were to move "lib1" elsewhere in your project, you would only need to adjust config.h.

François Andrieux
  • 28,148
  • 6
  • 56
  • 87
Maarten ten Velden
  • 53
  • 6
  • 1
    It would be better to just `#include "foo.h"` and in your compile command tell it about the include directory using the `-I` (capital 'eye') flag. But when you get to this point, you should be using a build system instead. – sweenish Feb 28 '21 at 16:11
  • 1
    *"why not add this as a feature for the preprocessor to?"* The answer is always the same. Because nobody proposed to add this to the standard, or the proposal was rejected. *"are there any preprocessors that support this syntax?"* Even if some compiler supported this, it would be non-standard. – HolyBlackCat Feb 28 '21 at 16:17
  • You would normally use a build system for this (generate an include file then include that). Similar question here: https://stackoverflow.com/q/40062883/5754656 – Artyer Feb 28 '21 at 16:31

2 Answers2

3

Why isn't this valid syntax?

Because the syntax for #include preprocessing directive is cpp.include for example:

 # include " q-char-sequence " new-line

The ( ) characters are not allowed there. Multiple " are also not allowed, and q-char is any member of the source character set **except** new-line and ".

why not add this as a feature for the preprocessor to?

Because it would require work. To implement it.

are there any preprocessors that support this syntax?

I very much doubt. No.

My thinking is that you could do something like..

And for limited cases you kind-of can, the form of preprocessing directive takes:

 # include pp-tokens new-line

For the usages, see this question. However not everything is possible, see this answer.

If you then were to move "lib1" elsewhere in your project, you would only need to adjust config.h.

No, the typical solution is to add include paths to your compiler. Then if you were to move lib1, you would change your build and compiler options, without any modification to the source code.

Keep your #include very simple - they are a very crude way to raw include other files. There is no reason to generate #include paths.

KamilCuk
  • 120,984
  • 8
  • 59
  • 111
1

Concatenation is defined for string literals, as you've illustrated. From cppreference on string literals :

String literals placed side-by-side are concatenated at translation phase 6 (after the preprocessor). That is, "Hello," " world!" yields the (single) string "Hello, world!"

But the "string" in an #include directive is not a technically a string literal. Looking at how #include is defined on cppreference : #include "filename" we can see that the filename is some token delimited by " characters. This looks a lot like a string literal, but this is a coincidence. A string literal defines an object. It has an address and a size and every other property an object can have. An #include does not define an object, it is a preprocessor directive.

François Andrieux
  • 28,148
  • 6
  • 56
  • 87