On Saturday, 21 April 2012 at 14:40:00 UTC, H. S. Teoh wrote:
> I'm getting confused about the use of 'static' in this context. What I
> wanted was to make the regex module-global, but apparently 'static' has
> an overloaded meaning here, and also makes it compile-time evaluated?
> How do I make it module-global without being compile-time evaluated??
>
>
> T

it just so happens to be that 'static' function variables in D require compile-time available initializers. To initialize with a runtime value on first execution, you have to implement that manually:

void foo(int a)
{
    static int first;
    static first_initialized = false;

    if(!first_initialized)
    {
        first = a;
        first_initialized = true;
    }

    // ...
}

On Sat, Apr 21, 2012 at 06:17:58PM +0200, nhk wrote:
> Please bear with my ignorance I'm new to D, but why is that any better compared to a simple
> 
> switch(key){
> default: throw Exception("Invalid attribute '%s'".format(key));
> case "name": d.name = value;
>                break;
> ...
> ...
> }

Firstly, the current version of dmd doesn't do any special translation
of a switch statement on a string variable, so it just becomes a
sequence of if-statements with string comparisons (slow). Using an
associative array makes the lookup O(1), which is fast(er) when you have
a lot of keys.

Second, using an AA allowed me to factor out the code that does the parsing (see the parseBlock function in the second version of my code). There's no way to do this with a switch statement.

In retrospect, the second point is probably more important, because the use of delegates probably delays the point at which AA performance starts to overtake a switch statement.


T

-- 
Caffeine underflow. Brain dumped.

On Saturday, 21 April 2012 at 14:40:00 UTC, H. S. Teoh wrote:
> On Sat, Apr 21, 2012 at 03:12:05PM +0400, Dmitry Olshansky wrote:
>> On 21.04.2012 14:48, SomeDude wrote:
>> >On Saturday, 21 April 2012 at 10:21:49 UTC, Dmitry Olshansky wrote:
>> >>Just stop using ctRegex for now... it's experimental.
>> >>
>> >>Or more to the point the problem is this. I've seen this one on bugzilla:
>> >>
>> >>version(CtRgx) {
>> >>enum Re = ctRegex!re;//auto is OK here BTW
>> >>} else {//that's the problem. It's _parsed_ at compile-time
>> >>static Re = regex(re);//switch static to auto
>> >>}
>> >>}
>> >>
>> >>And there is little I can do untill CTFE stops bleeding RAM.
>> >
>> >Well, neither of those works:
>> >
>> >version(CtRgx) {
>> >auto Re = ctRegex!re;//auto is OK here BTW
>> >} else {//that's the problem. It's _parsed_ at compile-time
>> >auto Re = regex(re);//switch static to auto
>> >}
> [...]
>
> Hmph. I should've checked dmd memory usage when I wrote that. :-(
>
> But anyway, even on my souped up AMD hexacore system, the ctRegex
> version takes significantly longer to compile than the non-ctRegex
> version. Perhaps I should just avoid ctRegex for now (though it *is* an
> ultracool feature of std.regex).
>
> T

Well, the big problem is, even if I fall back to runtime regex, I can't compile anymore on a Windows box with 2Gb of RAM. It's hard to swallow...

On Sun, Apr 22, 2012 at 12:31:16PM +0200, SomeDude wrote:
> On Saturday, 21 April 2012 at 14:40:00 UTC, H. S. Teoh wrote:
[...]
> >Hmph. I should've checked dmd memory usage when I wrote that. :-(
> >
> >But anyway, even on my souped up AMD hexacore system, the ctRegex version takes significantly longer to compile than the non-ctRegex version. Perhaps I should just avoid ctRegex for now (though it *is* an ultracool feature of std.regex).
> 
> Well, the big problem is, even if I fall back to runtime regex, I can't compile anymore on a Windows box with 2Gb of RAM. It's hard to swallow...

It's my fault. I really should be using module globals for those regexes, and a module ctor (static this) for initializing them.

It would be nice if the CTFE implementation was improved, though.  CTFE is one of the big major features of D that I really liked.

But speaking of which, are you using the latest version of dmd? 'cos I think recently there were some CTFE efficiency issues that got fixed.


T

-- 
"How are you doing?" "Doing what?"

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.2061.1335131543.4860.digitalmars-d@puremagic.com...
>
> It's my fault. I really should be using module globals for those regexes, and a module ctor (static this) for initializing them.
>

In most cases, I've come to prefer lazy initalization (via a module-level @property) over module ctors because:

1. If it never actually gets used, you avoid adding extra processing at startup merely because you imported some module.

2. It decreases the risk of hitting the dreaded cyclic-module-dependency error (major PITA).

And if you do want to throw away #1 and force initialization upon startup, you can still do that by simply accessing it at the beginning of main.

I've always felt module ctors were a great idea, but after hitting the cyclic dependency issue enough times (or even just the first time), I've come to think they're, unfortunately, best avoided.