Random D geekout

SomeDude lovelydear at mailmetrash.com
Sun Apr 22 03:31:16 PDT 2012


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...


More information about the Digitalmars-d mailing list