Problems in the C API.
| Appendix H. Wrapping C Libraries with gmmproc |

## Problems in the C API.

You are likely to encounter some problems in the library that you are wrapping, particularly if it is a new project. Here are some common problems, with solutions.

### Unable to predeclare structs

By convention, structs are declared in glib/GTK+-style headers like so:

    typedef struct _ExampleWidget ExampleWidget;

    struct _ExampleWidget
    {
      ...
    };

The extra typedef allows the struct to be used in a header without including its full defintion, simply by predeclaring it, by repeating that typedef. This means that you don't have to include the C library's header in your C++ header, thus keeping it out of your public API. gmmproc assumes that this technique was used, so you will see compiler errors if that is not the case.

This compiler error might look like this:

    example-widget.h:56: error: using typedef-name 'ExampleWidget' after 'struct'
    ../../libexample/libexamplemm/example-widget.h:34: error: 'ExampleWidget' has a previous declaration here
    make[4]: *** [example-widget.lo] Error 1

or this:

    example-widget.h:60: error: '_ExampleWidget ExampleWidget' redeclared as different kind of symbol
    ../../libexample/libexamplemm/example-widget.h:34: error: previous declaration of 'typedef struct _ExampleWidget ExampleWidget'

This is easy to correct in the C library, so do send a patch to the relevant maintainer.

### Lack of properties

By convention, glib/GTK+-style objects have *_new() functions, such as example_widget_new() that do nothing more than call g_object_new() and return the result. The input parameters are supplied to g_object_new() along with the names of the properties for which they are values. For instance,

    GtkWidget* example_widget_new(int something, const char* thing)
    {
            return g_object_new (EXAMPLE_TYPE_WIDGET, "something", something, "thing", thing, NULL);
    }

This allows language bindings to implement their own equivalents (such as C++ constructors), without using the *_new() function. This is often necessary so that they can actually instantiate a derived GType, to add their own hooks for signal handlers and vfuncs.

At the least, the _new() function should not use any private API (functions that are only in a .c file). Even when there are no functions, we can sometimes reimplement 2 or 3 lines of code in a _new() function as long as those lines of code use API that is available to us.

Another workaround is to add a *_construct() function that the C++ constructor can call after instantiating its own type. For instance,

    GtkWidget* example_widget_new(int something, const char* thing)
    {
    	ExampleWidget* widget;
            widget = g_object_new (EXAMPLE_TYPE_WIDGET, NULL);
    	example_widget_construct(widget, "something", something, "thing", thing);
    }

    void example_widget_construct(ExampleWidget* widget, int something, const char* thing)
    {
    	//Do stuff that uses private API:
    	widget->priv->thing = thing;
    	do_something(something);
    }

Adding properties, and ensuring that they interact properly with each other, is relatively difficult to correct in the C library, but it is possible, so do file a bug and try to send a patch to the relevant maintainer.

Initialization |  | Documentation