I am trying to port a heavily multithreaded C++ application to D.

I have a lot of variables that are set once from a config file at
runtime and then never change.
It seems that something like the following would be a very clean design.

module config;

static this()
{
    num_triggers = to!int(getValueFromConfigFile());
}

private:
immutable(int) num_triggers = void;

Is there any reason that allowing this would be a bad idea?

Am 22.02.2016 um 07:55 schrieb Danni Coy via Digitalmars-d:
> I am trying to port a heavily multithreaded C++ application to D.
>
> I have a lot of variables that are set once from a config file at
> runtime and then never change.
> It seems that something like the following would be a very clean design.
>
> module config;
>
> static this()
> {
>      num_triggers = to!int(getValueFromConfigFile());
> }
>
> private:
> immutable(int) num_triggers = void;
>
> Is there any reason that allowing this would be a bad idea?
>

This actually works already, if you use "shared static this". "static this" is invoked for each thread that is started, thus it would overwrite the existing value of num_triggers, potentially multiple times.

On 02/21/2016 10:55 PM, Danni Coy via Digitalmars-d wrote:
> I am trying to port a heavily multithreaded C++ application to D.
>
> I have a lot of variables that are set once from a config file at
> runtime and then never change.
> It seems that something like the following would be a very clean design.
>
> module config;
>
> static this()
> {
>      num_triggers = to!int(getValueFromConfigFile());
> }
>
> private:
> immutable(int) num_triggers = void;
>
> Is there any reason that allowing this would be a bad idea?
>

There is import() to read a config file at compile time:

module config;

string getValueFromConfigFile() {
    // Assume 'config_file' has just "42" in it:
    auto file_content = import("config_file");
    return file_content;
}

static this()
{
    import std.conv : to;
    num_triggers = to!int(getValueFromConfigFile());
}

private:
immutable(int) num_triggers;    // NOTE: '= void' did not work here

void main() {
    assert(num_triggers == 42);
}

Ali

On Mon, Feb 22, 2016 at 5:14 PM, Ali Çehreli <digitalmars-d@puremagic.com> wrote:

> There is import() to read a config file at compile time:

In my case the config files are there to allow end users to tune the application - therefore config files need to be read at runtime.

On Mon, Feb 22, 2016 at 5:09 PM, Sönke Ludwig <digitalmars-d@puremagic.com> wrote:
>
> This actually works already, if you use "shared static this". "static this" is invoked for each thread that is started, thus it would overwrite the existing value of num_triggers, potentially multiple times.

module config;

shared static this ()
{
    num_triggers = 1024;
}

private:
immutable(int) num_triggers = void;

is not working for me with dmd 2.070

Am 22.02.2016 um 08:27 schrieb Danni Coy via Digitalmars-d:
> On Mon, Feb 22, 2016 at 5:09 PM, Sönke Ludwig
> <digitalmars-d@puremagic.com> wrote:
>>
>> This actually works already, if you use "shared static this". "static this"
>> is invoked for each thread that is started, thus it would overwrite the
>> existing value of num_triggers, potentially multiple times.
>
> module config;
>
> shared static this ()
> {
>      num_triggers = 1024;
> }
>
> private:
> immutable(int) num_triggers = void;
>
> is not working for me with dmd 2.070
>

I was wrong, there is obviously a language/compiler bug here. It compiles if you remove the "= void", but it does so for "shared static this" as well as for "static this". It really shouldn't in the latter case.

On Mon, Feb 22, 2016 at 5:29 PM, Sönke Ludwig <digitalmars-d@puremagic.com> wrote:
> I was wrong, there is obviously a language/compiler bug here. It compiles if you remove the "= void", but it does so for "shared static this" as well as for "static this". It really shouldn't in the latter case.

Interesting... It definately seems like should work when explicitly asking the variable not the instantiated and not in a thread local initialiser.

On 2/22/16 2:36 AM, Danni Coy via Digitalmars-d wrote:
> On Mon, Feb 22, 2016 at 5:29 PM, Sönke Ludwig
> <digitalmars-d@puremagic.com> wrote:
>> I was wrong, there is obviously a language/compiler bug here. It compiles if
>> you remove the "= void", but it does so for "shared static this" as well as
>> for "static this". It really shouldn't in the latter case.
>
> Interesting... It definately seems like should work when explicitly
> asking the variable not the instantiated and not in a thread local
> initialiser.
>

I'm not sure the =void has any effect anyway, it's likely just going to write the entire static segment with some initial value.

So I'd say remove the =void, and you should be good.

-Steve

That worked however it seems that you can only do the assignments within the shared static this() and not from functions called by the initialiser which might change how I do things

On 2/22/16 9:58 AM, Danni Coy via Digitalmars-d wrote:
> That worked however it seems that you can only do the assignments
> within the shared static this() and not from functions called by the
> initialiser which might change how I do things
>

This is true. The compiler wants to be super-sure that you are only setting it once.

However, this can be alleviated by changing how you do things. Factor out the code that sets it, and have it instead return a value. Then you can do this:

shared static this() {
   num_triggers = myCrazyFunction();
}

Of course, myCrazyFunction must not depend on any other static variables, as those might not be initialized.

startup initialization can be very tricky.

-Steve