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