On 4/1/12, Artur Skawina <art.08.09@gmail.com> wrote:
> PS. Are there any sane Cairo D binding out there? (What's "sane"? Well, if
>     there's a "class" in there somewhere then it's not sane)

$ htod cairo.h

And the same goes for cairo_features.h, cairo_version.h, etc. I've used it on win32 samples with no issues.

Are you allergic to classes for some reason? CairoD has dispose() methods if you really want to manually deallocate Cairo handles.

Am Mon, 2 Apr 2012 08:17:24 +0200
schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> On 4/1/12, Artur Skawina <art.08.09@gmail.com> wrote:
> > PS. Are there any sane Cairo D binding out there? (What's "sane"? Well, if there's a "class" in there somewhere then it's not sane)
> 
> $ htod cairo.h
> 
> And the same goes for cairo_features.h, cairo_version.h, etc. I've used it on win32 samples with no issues.
> 
> Are you allergic to classes for some reason? CairoD has dispose() methods if you really want to manually deallocate Cairo handles.

https://github.com/jpf91/cairoD

I'll have to update it for cairo 1.12 though. New build scripts and some more small changes are also needed.

Just don't look at the high-level wrappers if you don't want to see "class" ;-) The main reason the wrappers use classes is inheritance. Cairo already has a object oriented API, so I think it makes sense to make ImageSurface a subclass of Surface, Gradients subclasses of Patterns, etc.

The biggest downside is that reference counting can't work this way. (And that classes need the GC, but once we have allocators and emplace is integrated with those, using classes without GC should be easier)