Jacob Carlborg wrote:
> On 2011-12-22 14:39, Timon Gehr wrote: >> On 12/22/2011 10:28 AM, Jacob Carlborg wrote: >>> On 2011-12-22 08:47, Johannes Pfau wrote: >>>> Hi, >>>> the following code is reduced from a parser generated with Ragel >>>> (http://www.complang.org/ragel/). That's also the reason why it's >>>> using pointers instead of array access, but Ragel guarantees that there >>>> won't be any out-of-bound reads. >>>> >>>> AFAIK pointers are supported in CTFE now as long as they're pointing >>>> to an >>>> array and there are no out-of-bounds reads. Still, the following code >>>> fails: >>>> >>>> -------------------- >>>> ubyte[4] testCTFE() >>>> { >>>> ubyte[4] data; >>>> string input = "8ab3060e2cba4f23b74cb52db3bdfb46"; >>>> auto p = input.ptr; >>>> p++; p++; >>>> data[0] = parse!ubyte((p-2)[0 .. 2], 16); >>>> p++; p++; >>>> data[1] = parse!ubyte((p-2)[0 .. 2], 16); >>>> p++; p++; >>>> data[2] = parse!ubyte((p-2)[0 .. 2], 16); >>>> p++; p++; >>>> data[3] = parse!ubyte((p-2)[0 .. 2], 16); >>>> p++; p++; >>>> return data; >>>> } >>>> enum ctfe = testCTFE(); >>>> >>>> void main() >>>> { >>>> import std.stdio; >>>> writeln(testCTFE()); //[138, 179, 6, 14] >>>> writeln(ctfe); //[138, 138, 138, 138] >>>> } >>>> -------------------- >>>> >>>> Has this bug already been filed? I could possibly circumvent it by >>>> making >>>> ragel use array indexing instead of pointers, but that'd be a >>>> performance >>>> issue for runtime code as well. >>> >>> Why would arrays be slower than pointers? You do know that you can turn >>> off array bounds checking? >>> >> >> Yes but the length has to be stored and updated, therefore for example >> p++ is less machine instructions/memory accesses/register pressure than >> arr = arr[1..$]. > > Ok, I see. Then this seems to be a very performance critical piece of > code. > In this special case it's not that important (simple UUID parser), but ragel is also used for HTTP parsers in webservers (lighttpd2), json parsers, etc and it's main advantage is speed.
