From: Rick M. <obj...@gm...> - 2007-10-24 19:00:20
|
Yes, for the most part, I was planning on changing a lot of those types to either size_t or an int where they were used as local variables or as method arguments and leaving the struct versions alone to get the optimal packing. Sort of bad design to have let the internal storage of those values leak out into the method interfaces like that. Rick On 10/24/07, Mark Miesfeld <mie...@gm...> wrote: > > Well, I tried to pick a first task that I thought was pretty straight > forward, and it mostly is. > > But, there are a few spots I'm struggling with, so I thought I get > Rick's advice. > > There are some places where CHAR is used, where is it used to limit a > number to 8 bits in size. > > For those I was going to uint8_t. Maybe they should go to size_t? > > Case in point. In InstructionParser.cpp around line 223: > > Index: kernel/parser/InstructionParser.cpp > =================================================================== > --- kernel/parser/InstructionParser.cpp (revision 1053) > +++ kernel/parser/InstructionParser.cpp (revision 1052) > @@ -220,8 +220,8 @@ > RexxObject *name; /* call > name */ > INT keyword; /* call > subkeyword */ > RexxString *condition; /* created USER > condition */ > - uint8_t flags; /* final CALL > flags */ > - uint8_t builtin_index; /* builtin function call > index */ > + CHAR flags; /* final CALL > flags */ > + CHAR builtin_index; /* builtin function call > index */ > > For builtin_index: currently all the tables are less than 255 in size. > But that is limiting. Should that be size_t instead? Or maybe > uint32_t? > > And, even though there are only a few flags, maybe that should just be > size_t (uint32_t) also? (In a modern architecture, I think it can be > counter-productive to make a variable smaller than a register size.) > > The reason I was going to change some of the CHAR to uint8_t is that > there are some structs where size things are defined using CHAR or > UCHAR. I didn't want to change the size of the struct. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |