Writing Shared Libraries, first draft

[Havoc Pennington]

On Mon, 2004-11-08 at 11:03 +0000, Mike Hearn wrote:
> Alexander Larsson wrote:
> > No. This is bad. It'll allow less functions to be added on arches with
> > 64bit function pointers than on 32bit, thus making half the allocated
> > padding space useless.
> 
> So using function pointers as padding is the correct thing to do then?
> 

Yeah, assuming non-opaque structs you should do what GTK does:

  /* Padding for future expansion */
  void (*_gtk_reserved1) (void);
  void (*_gtk_reserved2) (void);
  void (*_gtk_reserved3) (void);

Since this is the class struct and thus a global singleton, memory usage
isn't that big an issue, so usually I go to town and put in a bunch of
these things.

Though, with newer GObject you can add an interface instead of putting
more functions in the class struct, so the padding may not be as
essential.

I do agree with Scott that opaque types are better in all cases where
they are possible (nearly all cases IMO, but I don't think they are
possible for GObject class structs - instance structs should always be
opaque these days, though, since there's support for private instance
fields and "protected" fields can have accessors)

Havoc