[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