Re: Handling 'initializer element not constant' error

richard@[EMAIL PROTECTED]
 (Richard Tobin) writes:
> In article
<9c2b13d5-b18d-498e-aec8-d239d0bb3a23@[EMAIL PROTECTED]
>,
>  <vippstar@[EMAIL PROTECTED]
> wrote:
>
>>> It's a pity there isn't a standard way to get initialisation code run.
>
>>I don't think it's that much of a problem. Well-designed code wouldn't
>>use global variables.
>
> You're letting a slogan override your common sense.  There are many
> cases of global variables that are completely reasonable.
>
> For example, I want to convert between ISO Latin-5 (an 8-bit character
> set) and Unicode code points (which can be considered to have 2^16
> characters for this purpose).  To do this, I have a table of 256
> entries mapping Latin-5 to Unicode, and I want to build the reverse
> table at start-up.  These two global variables, latin_5_to_unicode and
> unicode_to_latin_5, have no objectionable properties.
[...]

Without resurrecting the unresolved argument over the definition of
"variable" I'll note that your global objects latin_5_to_unicode and
unicode_to_latin_5 presumably do not vary once they've been
initialized.  Global objects whose values are never modified during
program execution are less problematic than global objects whose
values can vary over time.  ("Global" here refers to file scope and
static duration, more or less.)

-- 
Keith Thompson (The_Other_Keith) <kst-u@[EMAIL PROTECTED]
>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"