Re: Official .defs files

[Karl Nelson <kenelson ece ucdavis 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?

Just some general comments.  There is no labor involved as I sent
a program which I use to extract them.  Thus it is easy for 
the standard extraction which generates many of the other fields
to pick them up.

Next varying a enum value by #ifdef magic is bad practice as best.
Changing one enum often reorders all of them after it and thus it
will instantly break binary compatiblity.  Thus I certainly don't
see valid reasons for coding enums with shifting values.

As for architecture specific ones, those would be imposible to
wrap.  To my knowledge there is no such beast in gtk+.  If there
were values in an enum which must be arch dependent, than they
certainly will not be pulled from the def file.



> 
> 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?

C++ uses this info at compile time as C does.  Thus 

  const static int i=1;

will not allocate memory in the object file and any multiplications
and other arthemetic operations will be evaluated at compile time
when possible.  Including the gtk+ headers means pulling many symbols
into the global namespace and thus gtkmm will need to wrap these constants.

(Further enums don't work like constants in C++ so we have to 
redeclare them or risk causing loads of unnecessary warnings.)

Hope that clears things up.

--Karl