enum ubyte[] vs enum ubyte[3]

Nick Voronin elfy.nv at gmail.com
Mon Dec 20 18:11:27 PST 2010


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.

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

-- 
Nick Voronin <elfy.nv at gmail.com>


More information about the Digitalmars-d-learn mailing list