Re: a better way to represent values

[Ben Pfaff]

For what it's worth, I'm pretty close to finishing up with this
work.  It's going to be a huge change set (and I'll definitely
want review for it), but it will be nice to drop all user-visible
distinctions between short and long strings (except those forced
upon us by the system file format).

Ben Pfaff <address@hidden> writes:

> Ben Pfaff <address@hidden> writes:
>
>> The only reason is simplicity.  Code that supports numeric and
>> short string data can just allocate a single "union value" for
>> each data item.  That makes life so easy: you can declare a
>> "union value" on the stack; you can declare an array of them and
>> index easily, and so on.
>>
>> Code that also supports long string data has to work harder,
>> because a single logical data item has to be allocated as an
>> array, just to support the rare case where the data is a long
>> string variable.  You then have to, usually, dynamically allocate
>> each individual data item, because there's no way to predict at
>> compile time how much space it will take up: it might be 8 bytes
>> or 32767 bytes.  Life is harder, and it takes more care to write
>> the code.
>>
>> So, we can "fix" this and related problems, but it's not as
>> simple as just flipping a switch and allowing long string
>> variables too.
>
> Because of this issue and other related ones that have popped up
> over the years, I've never really been happy with "union value".
> It's a pain to have to allocate more than one of them for the
> unusual case of a long string variable.
>
> So now I want to propose a new way to do it.  Change the
> definition of "union value" from this:
>
>     /* A numeric or short string value.
>        Multiple consecutive values represent a long string. */
>     union value
>       {
>         double f;
>         char s[MAX_SHORT_STRING];
>       };
>
> to this:
>
>     /* A numeric or string value.
>        Short string values are stored inline; long string values are
>        dynamically allocated. */
>     union value
>       {
>         double f;
>         char short_string[MAX_SHORT_STRING];
>         char *long_string;
>       };
>
> and add some helper functions to make dealing with the two
> different forms of storage for strings a bit easier.
>
> It's something of a big change, because there are a couple of
> hundred of references to the `s' member of union value in the
> source tree, and other related assumptions, but it will probably
> make a lot of other coding easier (as we can see from this
> thread).  I'm willing to do the conversion to this form myself
> (and I'll even try to update the developers guide to match).
>
> Any comments?

-- 
"I don't want to learn the constitution and the declaration of
 independence (marvelous poetry though it be) by heart, and worship the
 flag and believe that there is a god and the dollar is its prophet."
--Maarten Wiltink in the Monastery