Writing Shared Libraries, first draft

[Scott James Remnant]

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.

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