[cairo] Basic cairomm questions

Ian Britten britten at caris.com
Fri Aug 8 13:15:05 PDT 2008

Jonathon Jongsma wrote:

>> - What's the relationship between cairo and cairomm (Other than
>>    the obvious C++ wrapping)?  Is it maintained by the same people
>>    at the same time as cairo, or is it some sort of unofficial
>>    add-on, which might be lagging behind, abandoned someday, etc?
>>    [ Asked another way I guess - If I'm a C++ developer, why
>>      *wouldn't* I use cairomm?  What long-term risk/concern would
>>      I introduce to my project by using it? ]
> cairomm is not maintained by the same people that develop cairo. It is 
> usually slightly behind the base cairo library but not by much. You do 
> not have to worry about it being abandoned as it is a dependency of 
> gtkmm (which has been stable and actively developed for many years) and 
> is maintained by the same people.

Ok, that's encouraging!  cairomm it is then!  (Easier C++ code! :)

> Since you asked, here are a couple 
> reasons you might not want to use cairomm: the bindings are not 100% 
> complete at the moment (e.g. some of the more advanced text / glyph 
> API), though this is not really a problem in practice since you always 
> have access to the underlying C cairo objects and can use the C API 
> directly anytime you want to.

Ok, I've got no problem drilling-down every now and then.

> The other reason you might not want to use 
> cairomm is if you value raw speed above all else. Using exceptions, 
> smart pointers, etc. will obviously add a very small amount of runtime 
> overhead. In most cases, the overhead will be negligible, but in some 
> cases it might matter (which might translate into: if you're an 
> application developer, use cairomm, if you're a library developer, use 
> cairo)

Understood.  Even though I am a library developer, I think I'll still
proceed with cairomm.  I'm pretty sure the nature/volume of the data
we draw will far exceed any C++ overhead.
[ For example, ever try drawing a single polygon with +800 islands! ]

>> - If cairo and cairomm are "together":
>>    - Are they sync'd/released together, or do they maintain their
>>      own independent version numbers?
> The release management is separate and the version numbers are separate, 
> though obviously the minor release numbers will match (e.g. cairomm 
> 1.6.x wraps cairo 1.6.x, etc).

Ok, that's good to know.  Especially since I seem to be mixing 1.4
and 1.6 at the moment... :(   (Oops!)

> There will be variations in the micro 
> versions between cairomm and cairo, however. Because cairomm is only a 
> binding of cairo, when the base library fixes internal bugs and makes a 
> new release, the binding generally does not need to be updated, so we 
> don't always make new releases when cairo does.

No problem.

>> - What strategy does cairo(mm) use for error handling?  As a
>>    specific example, if an invalid path/filename is passed to
>>    the PdfSurface constructor (such that it can't create the
>>    requested file), how to I know that?  Exceptions?  Error
>>    numbers somewhere (Like errno)?  Inference? (ie: I get a NULL
>>    back, and guess what the problem might have been)  Other?
> In general, we try to model all error codes as exceptions.

Ah - I see Cairo::logic_error now...
Since our higher-level code is not exception-safe, I'd be looking
to catch any cairomm exceptions that are thrown, and downgrade
them to (our) errors.
- Is that the only type that is thrown? (Other than new, etc)
- Is there any guidance/docs about what may or may not throw?  Or
   should I simply wrap all my cairomm calls in try/catch blocks?
- Do all cairo/cairomm problems eventually manifest themselves as
   one of the cairo_status_t enum values?  If there's just that
   small set of unique errors, I'll probably just map them to some
   of our errors.

Thanks for all the valuable info!

More information about the cairo mailing list