Coincidentally, this topic just came up in conversation yesterday after a couple of years of not thinking about it. Strange synchronicity. :)
Here's a proposal on the subject from May 2016:
To Peter's question: no, you can't just put an #include directive inside a string, because "inside a string" there are by definition only characters.
"\
#include <foo>\
"
is equivalent (after backslash-replacement) to
"#include <foo>"
which doesn't have anything to do with a file named "foo" as far as the compiler is concerned.
So the above-linked proposal — which was extensively discussed on this very mailing list; maybe you can dig up the thread(s) — proposed that we introduce a completely new kind of string literal: F"foo" means "open the file named foo and dump its contents into this string."
I don't know whether the proposal was ever discussed in Committee. Personally I think it has two major hurdles to overcome:
- it's a preprocessor feature request, and changing the preprocessor sucks (because C compatibility; because modules)
- it's proposing a completely new dimension of stringness, on top of the two dimensions we already have
Consider: if F"foo" is the contents of file foo, what is u8F"foo"? what is LF"foo"? In short, what is the interaction between the C++ notions of "character set" and "encoding" with the filesystem concept of "the text stored in this file"? — Please note that this horse was absolutely beaten to death in the old thread, so I do recommend that you go dig it up and read it. But, for people who aren't the OP and yet might still want to debate the topic, please do
read the proposal P0373r0, since it has a lot to say on the subject and can get you up to speed on the issues relatively quickly.
HTH,
–Arthur