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

[Rui Pires <themidgard gmail com>]

> If it is a problem, then the proposed disabling of exceptions would
> mostly eliminate it, by leaving us with just one extra
> if(exceptions_enable) for each function call. I can't imagine what you'd
> be drawing for which that would be a significant amount of work.

Even better, make two classes (maybe using a template? I'm no C++ expert)
which have identical code except with a different initialization value for
the constant "exceptions_enable", that way the dead code elimination pass
will delete the check entirely and you have optimal code. Then the
programmer can just switch between them using "new CheckedCairo" or "new
Cairo" for instance.

This was (almost) what I was talking about when i sugested we used policies to define the wrapper's behaviour.
The police would be a class that would be used as a parameter to the wrapper classes, and would contain a callback that was called after each cairo function that might generate an error. Now, the beauty of using policies is that it makes the wrapper open to the choices of the user. For example, this callback might simply be inlined and empty (i.e.: would result in absolutely no code in the final executable), allowing us to have no runtime overhead whatsoever and simply use a wrapped test status function (and use it like Bill Spitzak was sugesting). Of course this would be the behaviour defined by one policy, another could check for erros (using an inline method) and throw exceptions. Another could check for errors, using a regular method, etc ...

Giving the user three or four predefined policies with the wrapper, and the ability to writte any one he/she can think of will certainly make Cairomm a more flexible wrapper.

I will try to write some code to explain what i'm talking about some time soon (or you can take a look at the use of policies in "big" projects such as boost (notibly boost:spirit) and lib loki)

__
Rui Pires