Re: [cairo] Re: Re: cairo c++ bindings

[chris nuernberger <cnuernber gmail com>]

The _only_ thing I want in the wrapper is to take care of redundant
function arguments and to (as best as possible) ensure that I don't
have to worry about reference counting and such.  The point is
definitely not to create something that is a long way away from the
well-thought out and well-designed interface that already exists.  It
is really just to make things easier using the features of the
language that are effective at doing so; namely the
constructor/destructor/copy semantics that c++ does well at
respecting.

Using a template argument that specifies the error handling strategy
for each object makes a lot of sense.

The further you get from exactly the designed functionality, the more
leaks your abstraction is going to have and the more leaks users are
going to have to patch.

To recap, I would like these things abstracted: reference counting,
redundant arguments.  Anything else, if it gets in my way whatsoever,
is going to aggravate me because I can add it if I need it.  I don't
need someone else's assumptions about what is an error and what isn't
or anything else.

This list has argued for a while about the stupid error handling
strategy.  Use a template, parameterize it, and be done with it. 
Implement things in the header, and then use doxygen or something so
no-one has to read the headers, then you solve both problems of no
overhead (as the compiler will inline most that it can, not that I
really believe this will be very much anyway) and ease of use.  Use
the constructors, copy constructors, and destructors to implement
whatever lifetime-management strategies are necessary so that your
objects can be safely copied, constructed, and destroyed.  That allows
you to easily use different allocation strategies or just the stack
and ignore most of the problem in general.   Done correctly you don't
even have to link with a different library (other than cairo in the
first place); just include the headers you need and you are finished. 
That is the way that the STL works, that is the way that most of Boost
works, that is in general a very c++ way of doing things.

Hell, you could probably write _one_ code generator that scanned a few
cairo headers and simple wrote wrapper c++ objects for each cairo
struct automatically, including the method calls and the c++ wrapper
is completely finished in under 1 week, and people using it don't have
to do anything other than include the headers that correspond to their
cairo implementation and pick and error handling strategy.

Actually, it really comes down to this:  Whoever decides to do it does
whatever the hell they want.  Its not like we are talking about a
difficult project here.  Its a wrapper around an already well-defined
interface.  Not a space-shuttle.

By the way, who is the lucky bloke who wants to implement this
minefield of a project?