enum ubyte[] vs enum ubyte[3]

[Johannes Pfau]

On Tuesday, December 21, 2010, Nick Voronin <elfy.nv at gmail.com> wrote:

> On Mon, 20 Dec 2010 17:17:05 +0100
> "Johannes Pfau" <spam at example.com> wrote:
>
>> > But if you are going to patch it, please make it add extra {} around
>> > action code! The thing is that when there is a label before {} block
>> > (and in ragel generated code I saw it's always so) the block isn't
>> > considered as a new scope which causes problems when you have local
>> > variables declaration inside actions.
>>
>> You mean like this code:
>> ---------------------------------
>> tr15:
>> #line 228 "jpf/http/parser.rl"
>>      {
>>          if(start != p)
>>          {
>>              key = line[(start - line.ptr) .. (p - line.ptr)];
>>          }
>>      }
>> ---------------------------------
>> should become: ?
>> ---------------------------------
>> tr15:
>> #line 228 "jpf/http/parser.rl"
>>      {{
>>          if(start != p)
>>          {
>>              key = line[(start - line.ptr) .. (p - line.ptr)];
>>          }
>>      }}
>> ---------------------------------
>
> Yes. This way it becomes a scope which is kind of what one would expect  
> from it.
OK, I sent an updated patch to the ragel mailing list.

>
>> > One is fixed size array and other is dynamic. Honestly I doubt that it
>> > matters for code generated by Ragel, since this is constant and won't  
>> be
>> > passed around. If it's harder to make it fixed-size then don't bother.
>> >
>> Could a dynamic array cause heap allocations, even if it's data is never
>> changed? If not, dynamic arrays would work fine.
>
> Sorry, I can't provide reliable information on what can happen in  
> general, but right now there is no difference in produced code accessing  
> elements of enum ubyte[] and enum ubyte[30]. In both cases constants are  
> directly embedded in code.
>
> In fact as long as you only access its elements (no passing array as an  
> argument, no assignment to another variable and no accessing .ptr) there  
> is no array object at all. If you do -- new object is created every time  
> you do. I believe Ragel doesn't generate code which passes tables  
> around, so it doesn't matter.
>
Well Adrian Thurston said he'd look into this issue when he merges the D2  
patch, so I guess we'll get the correct arrays anyway ;-)

-- 
Johannes Pfau