Writing Shared Libraries, first draft

Scott James Remnant scott at netsplit.com
Mon Nov 8 14:42:16 EET 2004

On Mon, 2004-11-08 at 13:35 +0100, Sven Neumann wrote:

> Scott James Remnant <scott at netsplit.com> writes:
> > No, the right thing to do is to make sure your API doesn't rely on the
> > size of the structure.
> This isn't always possible since it effectively keeps you from
> "deriving" from this structure. It is for example not an option for an
> instance struct based on GObject unless you want that class to be
> final (in the Java sense).
From rom gtkaction.h:

typedef struct _GtkAction      GtkAction;
typedef struct _GtkActionPrivate GtkActionPrivate;

struct _GtkAction
  GObject object;

  /*< private >*/

  GtkActionPrivate *private_data;

The private content of the struct is never elaborated, and is simply
available through a pointer.  You can still derive from GtkAction
because the size of *that* struct is known, and the gtk_action code can
still obtain its private data through pointer.

Note that this trick doesn't work the class structs, so they are padded
with function pointers ... because we *know* we're only ever going to
expand those using other function pointers.

Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20041108/c3ef2051/attachment.pgp 

More information about the xdg mailing list