Re: user-defined function & string file name

[Ethan A M. <merritt@u.washington.edu>]

On Monday 04 July 2005 02:23 am, Juergen Wieferink wrote:
> Hans-Bernhard Broeker wrote:
> > Juergen Wieferink wrote:
> > > Enabling strings in this special case would be to define "STRING"
> > > and to extend the union within "struct value" by "string_val".  This
> > > itself should not lead to additional code in the executable.
> >
> > That would only be true if we were certain that all usages of the
> > union are already fully decoded, i.e. the switch(value.type) all have
> > cases for each of the allowed values, and there are no if(value.type
> > == INTGR) or similar.  That's not quite true right now, even though
> > we're surprisingly close to that goal.
>
> I don't understand this, and I feel really should.  Is there really
> a problem with "if (value.type == INTGR)", or would it be the "else"
> part that makes problems?

The internal evaluation code uses switch(value.type) statements everywhere.
At the very least, if you add a new type without adding new case
statements you will cause compiler warnings.  Easy enough to do, but my
feeling is that if you want to go to this trouble then we might just as
well remove the conditional compilation flags around the string variable
code and leave it at that.
-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742