Parse File at compile time, but not embedded
Joerg Joergonson via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Fri Jun 10 11:47:59 PDT 2016
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.
More information about the Digitalmars-d-learn
mailing list