c types problem

G|sta Simil{/ml gostas at kuling.UUCP
Sat Jan 11 17:12:32 AEST 1986


In article <175 at hadron.UUCP> jsdy at hadron.UUCP (Joseph S. D. Yao) writes:
>In article <168 at hadron.UUCP> jsdy at hadron.UUCP (Joseph S. D. Yao) writes:
>>In article <870 at kuling.UUCP> gostas at kuling.UUCP (G|sta Simil{/ml) writes:
>>>The formal (but ugly) way to solve this would proparbly be to use a union
>>>for all (about 10) types. But now I wonder if anyone have a simpler but
>>>resonably portable solution?
>> ...
>
>My original answer dealt with a union of outputs.  Re-reading the
>message, it seems that you are talking about a union of inputs.
>Oh, well, the principle remains the same.

>	Joe Yao		hadron!jsdy at seismo.{CSS.GOV,ARPA,UUCP}

Yes, it's a union of inputs, no value will be returned and the calling program
will have no idea what type the called functions are using currently, the
code will look something like this:

/* calling routine: */
typemix *base;  /* malloc()'ed array, may change size during execution */

	current_data = base;
	for (current_data = base; (something); current_data++, p++)
		if ((*p->function)(current_data))  /* value changed? */
			(*p->action)();  /* really just a print routine */

/* called function: */

func(old_value)
typemix *old_value;
{
	some_type new_value = get_new_value();

	if (new_value == old_value->some_type)
		return(0);
	old_value->some_type = new_value;
	return(1);
}

The example will be used when updating a screen, to avoid printing a field
which have not changed value since the last update.

	G|sta Simil{				gostas at kuling.UUCP



More information about the Comp.lang.c mailing list