From: TP Diffenbach <rockbox_at_diffenbach.org>
Date: Tue, 29 Apr 2003 11:59:28 -0400

Quoting Linus Nielsen Feltzing <linus_at_haxx.se>:

> TP Diffenbach wrote:

> Still, there is no function that can provide a char ** array to the
> strings. You'll have to write one.

There's no need to write a function. str( FOO ) gives me a pointer to a language string. str( x ) is a macro that expands to language_strings[ x ]. langauge_strings is an array of unsigned char* .

So by using the address-of aoperator, &, &str( FOO ) gives me a pointer to a pointer to an unsigned char: unsigned char**. Because in C array names are (in most cases) treated as pointers to the first element of the array, &str( FOO ) can be treated as an array, with parethesizing to override C's operator precedence:

( &str( FOO ) )[ x ] is defined as *( &str( FOO ) + x ). str( FOO ) is a poointer to unsigned char, so &str( FOO ) is an unsigned char**, + x is pointer arithmetic on an unsigned char**, so the resulting expression is an unsigned char**, *( unsigned char**) is an unsigned char*.

So, ( &str( FOO )[ x ] gives me the x'th unsigned char* in language_strings after language_strings[ FOO ] (or language_strings[ FOO } itself when x is zero)>

> However, it could be considered bad practice to depend on the order of
> the language strings. With todays system, you can be sure that the
> strings are in the same order as in the english.lang file, but maybe not
> tomorrow.

I'm only considering depending on the order of strings that "should" be ordered: all the options for a particular setting, from the first option through to the last option. I'll still index into language_strings via the enum constant on teh first one. Of course, I'll also be relying on the number of strings in the series. (Perhaps the .lang file could be modified to indicat this, and the .lang handling scripts modified to generate an enum constant for this too.)

This additionaly allows us to write .cfg files in the user's curently selected langauge, and, as the language file entry is prior to any translated settings in the .cfg, to read .cfg files in any langauage for which we can load the lanaguage file. Code will have to be added to abort a .cfg load if the approproate lanaguage file cannot be loaded, and to so inform the user.

Further, by getting hard-coded English strings out of settings.c, we get rid of having two copies of each hardcoded string, one for read and one for write (unless the linker combines equal strings? Does gcc really optimize that well?), plus whatever strings are used in the user interface settings screens. This will save a good deal of code/data space in the .ajz.

So we gain .cfg files translated on write and on read, we save space by having only a single copy of each string in memory, and it's all legal C. We lose the ability to reorder strings in the .lang file which naturally should be ordered anyway (and any re-ording causes us to bump a version number, so it's not likely to happen often or mistakenly). To me, the gain outweighs the cost.

What do you think?

-- 
Archos FM needs a Rockbox!

Received on 2003-04-29