[cairo] Re: cairo c++ bindings

Murray Cumming murrayc at murrayc.com
Wed Nov 23 08:16:02 PST 2005


> Hi everyone,
>
>> > here's a preview
>> >
>> > http://downloads.paniq.org/cairo.hpp
>>
>> Excellent. I encourage everyone to take a look and think about how the
>> bindings should look.
>
> I'm pretty new to cairo, but I've worked on a small, quite different
> C++ wrapper and I'm a little surprised of the points I read here.
> I hope my questions/remarks can interest some of you ;)
>
>> - It's desirable to hide the C headers from the C++ headers. Among other
>>   things, that means:
>>   - using numbers instead of enum values for the C++ enum values, as in
>>     gtkmm.
>
> Isn't there a risk to have the C++ enum values desynchronized with the
> C ones by doing that?

Yes, it would require automatic generation, as we use in glibmm. For now,
I've just typedefed the enums.

>>   - not deriving from the C struct unless it's really necessary.
>
> It seems to me that deriving from the C struct is highly dangerous:
> what happen if, for a reason or another the compiler decides to add
> informations before the "relevant" data block?
> Like in:
>
> class Matrix : public cairo_matrix_t
> {
>   void init_identity()
>   {
>     cairo_matrix_init_identity(this);
>   }
> };
>
> What happen if the data that cairo_matrix_init_identity is expecting
> are not at the same address as this? (let imagine a pointer to a
> potential virtual table...)

struct inheritance is a fairly reliable hack that GTK+ (and gtkmm) has
been using for a long time on a lot of platforms.

Anyway, as I said, I don't want to do this anyway.

>>   - forward-declaring C struct types and using them as little as
>> possible
>>     in headers. #include the definition in the .cc file.
>
> But a wrapper should come with the smallest possible overhead, so most
> of the methods should be hinted as inline, making the #include
> <cairo.h> in the .hh necessary. (It is also needed to ensure the
> synchronization of the C and C++ enumerations).

inline is an optimisation. Optimisation should be targetted and based on
tests. I'm not going to make a library that's just a header.

>> - Non-copyable classes should have a private, undefined, copy
>> constructor.
>> - The operator * and operator = overrides are a little odd. I'd prefer
>>   explicit conversion, and that's the style used by gtkmm.
>
> In my opinion, a nice cairo C++ wrapper should help a developper by
> hidding him implementation details, such as the necessity of
> explicitely calling "cairo_*_reference" at each object copy.

Yes. Already done.

[snip]
> What do you think?

I suggest that you wait a day or so until I've had a chance to check it
into cvs. It's not a difficult wrapper to write, so there shouldn't be
much room for disagreement.

Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com



More information about the cairo mailing list