Function to call #include macro from a string variable argument?

Question

Is it possible to have a function like this:

const char* load(const char* filename_){
    return
    #include filename_
    ;
};

so you wouldn't have to hardcode the #include file?

Maybe with a some macro?

I'm drawing a blank, guys. I can't tell if it's flat out not possible or if it just has a weird solution.

EDIT:

Also, the ideal is to have this as a compile time operation, otherwise I know there's more standard ways to read a file. Hence thinking about #include in the first place.

Answer 1

This is absolutely impossible.

The reason is - as Justin already said in a comment - that #include is evaluated at compile time.

To include files during run time would require a complete compiler "on board" of the program. A lot of script languages support things like that, but C++ is a compiled language and works different: Compile and run time are strictly separated.

Answer 2

I can't tell if it's flat out not possible

I can. It's flat out not possible.

Contents of the filename_ string are not determined until runtime - the content is unknown when the pre processor is run. Pre-processor macros are processed before compilation (or as first step of compilation depending on your perspective).

When the choice of the filename is determined at runtime, the file must also be read at runtime (for example using a fstream).

Also, the ideal is to have this as a compile time operation

The latest time you can affect the choice of included file is when the preprocessor runs. What you can use to affect the file is a pre-processor macro:

#define filename_ "path/to/file"

// ...
return
#include filename_
;

Answer 3

You cannot use #include to do what you want to do.

The C++ way of implementing such a function is:

1. Find out the size of the file.
2. Allocate memory for the contents of the file.
3. Read the contents of the file into the allocated memory.
4. Return the contents of the file to the calling function.

It will better to change the return type to std::string to ease the burden of dealing with dynamically allocated memory.

std::string load(const char* filename)
{
   std::string contents;

   // Open the file
   std::ifstream in(filename);

   // If there is a problem in opening the file, deal with it.
   if ( !in )
   {
      // Problem. Figure out what to do with it.
   }

   // Move to the end of the file.
   in.seekg(0, std::ifstream::end);

   auto size = in.tellg();

   // Allocate memory for the contents.
   // Add an additional character for the terminating null character.
   contents.resize(size+1);

   // Rewind the file.
   in.seekg(0);

   // Read the contents
   auto n = in.read(contents.data(), size);
   if ( n != size )
   {
      // Problem. Figure out what to do with it.
   }

   contents[size] = '\0';
   return contents;
};

PS

Using a terminating null character in the returned object is necessary only if you need to treat the contents of the returned object as a null terminated string for some reason. Otherwise, it maybe omitted.

Answer 4

it is theoretically possible.

In practice, you're asking to write a PHP construct using C++. It can be done, as too many things can, but you need some awkward prerequisites.

• a compiler has to be linked into your executable. Because the operation you call "hardcoding" is essential for the code to be executed.

• a (probably very fussy) linker again into your executable, to merge the new code and resolve any function calls etc. in both directions.

Also, the newly imported code would not be reachable by the rest of the program which was not written (and certainly not compiled!) with that information in mind. So you would need an entry point and a means of exchanging information. Then in this block of information you could even put pointers to code to be called.

Not all architectures and OSes will support this, because "data" and "code" are two concerns best left separate. Code is potentially harmful; think of it as nitric acid. External data is fluid and slippery, like glycerine. And handling nitroglycerine is, as I said, possible. Practical and safe are something completely different.

Once the prerequisites were met, you would have two or three nice extra functions and could write:

void *load(const char* filename, void *data) {
    // some "don't load twice" functionality is probably needed
    void *code = compile_source(filename);
    if (NULL == code) {
        // a get_last_compiler_error() would be useful
        return NULL;
    }
    if (EXIT_SUCCESS != invoke_code(code, data)) {
        // a get_last_runtime_error() would also be useful
        release_code(code);
        return NULL;
    }
    // it is now the caller's responsibility to release the code.
    return code;
}

And of course it would be a security nightmare, with source code left lying around and being imported into a running application.

Maintaining the code would be a different, but equally scary nightmare, because you'd be needing two toolchains - one to build the executable, one embedded inside said executable - and they wouldn't necessarily be automatically compatible. You'd be crying loud for all the bugs of the realm to come and rejoice.

What problem would be solved?

Implementing require_once in C++ might be fun, but you thought it could answer a problem you have. Which is it exactly? Maybe it can be solved in a more C++ish way.

A better alternative, considering also performances etc., to compile a loadable module beforehand, and load it at runtime.

If you need to perform small tunings to the executable, place parameters into an external configuration file and provide a mechanism to reload it. Once the modules conform to a fixed specification, you can even provide "plugins" that weren't available when the executable was first developed.