On 10.11.2010, at 13:11, Albrecht Schlosser wrote:
>
> Ian (SELEX GALILEO, UK) wrote:
>> Well... char may be a poor choice here; on a lot of modern CPU's (and
>> particularly ARM cores for example) it is often more expensive to access
>> a char than a int32, and does not save any memory because the alignment
>> is forced to 32 (or even 64!) bit anyway.
>>
>> So, for a "fast and light" implementation, it is possible that some sort
>> of int is a better bet than a char.
>
> Yes, I guess that int would probably be a good choice for API and
> internal variables. Maybe bool or char could be used as member
> variables in classes, if memory usage is a concern (if we assume
> that there is no padding between member variables...).
The ARM cpus don't have 16 bit access functions, but they do have 8 bit
functions that are exactly as fast as the 32 bit ones. Also, even if alignment
is 32 or 64 bit, consecutive byte values in a struct/class will still be packed
at byte boundaries. This does of course not help in case of return value which
goes into a register anyways.
struct good {
int a;
char b, c, d, e;
int e;
} // should be 12 bytes on a 32-bit machine
but
struct bad {
char a;
int b;
char c;
int d;
} // will be 16 bytes on a 32-bit machine
struct tiny {
int a;
unsigned char b:1, c:1, d:1, e:1, f:1, g:1 ....;
int zz;
} // will still be 12 bytes, assuming less than 32 flags, and will still be a
single command on an ARM cpu for getting an setting. Granted, the compiler may
add some noise in this particular case.
To conclude, I would like to continue to use 'bool' if everybody is 'true' with
that. ;-)
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
