Re: Official .defs files

[Karl Nelson <kenelson ece ucdavis edu>]

> Karl Nelson <kenelson ece ucdavis edu> writes:

Havocs answer is good enough, but I will be my usual self and
beat the topic to death.

(In long and gory detail.)

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

Gtkmmproc (the gtkmm code generator) wishs to generate all the enum
wrappers by automated means.  In the cases, were there is something which 
is not straight forword (not possible to know value without looking at 
architecture) I will simply not mark it in the generator header file as 
capable of being pulled in.  

Just some background...  gtkmmproc source files don't pull in ALL symbols
raw to make a fully automated wrapper.  That would yield a fairly low
quality binding for C++ basically just C in C++ syntax.  (see sugar)
To avoid that we have always used a kind of skeleton header which tells
how to pull the symbols in to fit the oranization of the C++ binding.

_ENUM(ReliefStyle,ReliefStyle)

class Button : public Bin {
  _CLASS(Button,GtkButton,GTK_BUTTON,Gtk::Bin,GtkBin)
  _CTOR_DEFAULT
  _CTOR_CAST
  _DTOR
  explicit Button(const string &label,gfloat x=0.5,gfloat y=0.5);
  _WRAP(meth,void set_relief(ReliefStyle newstyle),gtk_button_set_relief)
  _WRAP(meth,ReliefStyle get_relief(),gtk_button_get_relief)
  _WRAP(meth|sig|impl,void pressed(),gtk_button_pressed,"pressed")
  _WRAP(meth|sig|impl,void released(),gtk_button_released,"released")
};

Thus allowing any mixture of automatic and hand binding.  (All the 
bindings do this to some extent; gtkmm is just a lot more
hand than most.)

So any enum which is dependent on gtk+ headers will get a hand
wrapper like...

h:
extern const int BITS_PER_PIXEL;  // changes with archituture

c:
const int BITS_PER_PIXEL=GTK_BITS_PER_PIXEL; 

This is bad in that it does not allow for optimizations but still
avoids including the gtk+ headers.


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

Using enums as a general constant formulation is considered bad practice in
C++.  Not that that means gtk+ in C should avoid it.  The alternative
in C which is to use #defines for all bit masking is just as bad.  Thus
I am not stating that we should restrict the C codes form to what C++
(or insert your own favorite language here.)

I am stating if those enums which are fixed (99.9% of them) in the C code 
are not available in the defs file, then the only way for C++ to wrap the 
enums would be to do the hard and inefficent mechanism.  
The defs file is meant to be convient to all the wrappers.  I am
sure there are things there for Perl, Python and others which will
be of little use to C++ bindings (especially one were skeleton headers
like gtkmm are used.)  Having the values where they are known ahead of
time in the defs would be a great benifit for 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.

Your argument seems to be because one or two rare cases of enums
changing values of architecture that having the numerical values 
in the defs file is worthless.  It is quite valuable in time saving 
for a C++ compile and the general the wrapper should not have to
pull in every symbol of the stuff it is wrapping (least they just
skip the wrapper entirely.)  

If there really must be shifting values on enums (bad practice in
general), then simply have the defs file make  #v for that enum
(meaning value is variable from system to system.)  If it is 
variable then I obviously will have to wrap it by hand.  Still
for 99.9% of the other cases, it is of great benifit.


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

Certainly it should be considered.  I just don't think it should
be a show stopper.  The defs file already involves merging information
which can't be known by simple extraction.  Conditional compiling
enums certainly fit this bill.


(There are things which should be avoided like...

enum {
   ENUM1,
#ifdef SOMETHING
   ENUM2,
#endif
   ENUM3
}

Because it causes unnecessary binary problems and will be a total
pain in the ass to extract.)

I personally doubt I will ever be able to fully break dependency
in gtkmm on gtk+ headers.  This is just one step necessary toward
that ultimate goal.

--Karl