Re: Official .defs files

[Rob Browning <rlb cs utexas edu>]

Karl Nelson <kenelson ece ucdavis edu> writes:

> Thus there is a compelling need for the c-values to be in the 
> file.  Further, getting the value from the order implies they
> won't get sorted or otherwise mangled anywhere in the process.
> Be safe and place it in the spec.  Worst case, most of the 
> bindings just skip over that field.

Putting the values in the .defs of course means that the defs has to
be updated every time the header enum values change, and aside from
the extra labor, seems possibly incorrect/dangerous.  As an example,
what do you do for cases where the values of the enums vary depending
on some header #ifdef magic?  For example, what if the values are
architecture specific?

IMO, for .defs system that's intending to wrap real C APIs, the values
need to be determined at compile time.  FWIW, g-wrap just includes the
relevant C header(s) and builds functions that handle the
symbol(s)->val and val->symbol(s) conversions at runtime.  In C++, you
can actually just use the information statically, can't you?

(Sorry if I'm overlooking something obvious.)

-- 
Rob Browning <rlb cs utexas edu> PGP=E80E0D04F521A094 532B97F5D64E3930