Re: Official .defs files

[Rob Browning <rlb cs utexas edu>]

Karl Nelson <kenelson ece ucdavis edu> writes:

> As for architecture specific ones, those would be imposible to wrap.

I don't understand why.  If in some software BITS_PER_PIXEL == 16 on
m68k, and BITS_PER_PIXEL == 32 on i386, I don't see why the wrappers
can't pick that up at compile time.  G-wrap certainly will.

> 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.)

Your counter-argument here seems to be that certain changes should be
avoided because they'll be harder to wrap in C++.  That doesn't seem
like a strong counter-argument to me.  People using garbage collected
languages, for example, could make similar arguments about the C API's
allocation policies, but if the goal is to try and come up with a
general .defs file that will apply to a wide range of C APIs then you
don't have a lot of control over what the API might look like, and
need to be flexible.

(However, if I've gotten the wrong impression, and you're really just
 talking about a .defs file for the gtk API, then my comments
 obviously aren't as appropriate.)

Overall, I just wanted to make sure people had at least considered the
conditional compilation issues wrt enums.

Thanks

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