[cairo] Basic cairomm questions

[Ian Britten]

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!
Ian