On Friday, 10 June 2016 at 12:48:43 UTC, Alex Parrill wrote:
On Thursday, 9 June 2016 at 22:02:44 UTC, Joerg Joergonson wrote:
On Tuesday, 7 June 2016 at 22:09:58 UTC, Alex Parrill wrote:
Accessing a SQL server at compile time seems like a huge abuse of CTFE (and I'm pretty sure it's impossible at the moment). Why do I need to install and set up a MySQL database in order to build your software?

Lol, who says you have access to my software? You know, the problem with assumptions is that they generally make no sense when you actually think about them.

By "I" I meant "someone new coming into the project", such as a new hire or someone that will be maintaining your program while you work on other things.

In any case, this is impossible. D has no such concept as "compile-time-only" values, so any usage of a value risks embedding it into the binary.

It seems that dmd does not remove the data if it is used in any way. When I started using the code, the data then appeared in the binary.

The access to the code is through the following

auto SetupData(string filename)
{
   enum d = ParseData!(filename);
   //pragma(msg, d);
   mixin(d);
   return data;
}

The enum d does not have the data in it as showing by the pragma. ParseData simply determines how to build data depending on external state and uses import(filename) to get data.

Since the code compiles, obviously d is a CT constant. But after actually using "data" and doing some work with it, the imported file showed up in the binary.

Of course, if I just copy the pragma output and paste it in place of the first 3 lines, the external file it isn't added to the binary(since there are obviously then no references to it).

So, at least for DMD, it doesn't do a good job at removing "dangling" references. I haven't tried GDC or LDC.

You could probably use somethign like

string ParseData(string filename)()
{
   auto lines[] = import(splitLines(import(filename)));
   if (lines[0] == "XXXyyyZZZ33322211")
      return "int data = 3";
   return "int data = 4";
}

So the idea is if the external file contains XXXyyyZZZ33322211 we create an int with value 3 and if not then with 4.

The point is, though, that `XXXyyyZZZ33322211` should never be in the binary since ParseData is never called at run-time. At compile time, the compiler executes ParseData as CTFE and is able to generate the mixin string as if directly typed "int data = 3;" or "int data = 4;" instead.

The only difference between my code and the above is the generated string that is returned.

I'm going to assume it's a dmd thing for now until I'm able check it out with another compiler.









Reply via email to