[cairo] CAIROMM: Status type and Xlib

[Murray Cumming]

On Sat, 2006-01-14 at 23:49 -0600, Jonathon Jongsma wrote:
> On 1/14/06, Jim Gettys <jg at freedesktop.org> wrote:
> > On Thu, 2006-01-12 at 08:41 -0600, Jonathon Jongsma wrote:
> > > In experimenting with implementing a heirarchy of surfaces in cairomm,
> > > I've run across a problem that took me a while to track down.  cairomm
> > > typedefs cairo_status_t as Cairo::Status.  This was working fine until
> > > I added support for XlibSurface, which needs to pull in a bunch of
> > > xlib headers.  The problem is that Xlib.h contains the line:
> > >
> > > #define Status int
> > >
> > > So any Status type that occurs after Xlib.h is included gets replaced
> > > by the preprocessor with 'int'.  I don't know why it's a #define
> > > instead of a typedef.
> >
> > Hysterical reasons: typedef wasn't available universally at the time
> > that line was written, IIRC.
> >
> > #undef is your friend.
> >                         - Jim
> >
> 
> I'm using #undef currently to work around this in my development code,
> but I figure that if somebody is using the XlibSurface in cairo, they
> will need to write code that uses XLib, so #undef-ing a type would
> theoretically cause problems in any code that they wrote which
> attempted to use XLib's Status type, no?
> 
> Murray, was your plan to remove the Status type from API completely
> and only use exceptions when an error occurred?

Sorry for the late reply. I didn't see this until now.

Yes, I think it would be OK to remove get_status() from the public API. 

But we still need some non-public (or marked as internal in the
documentation) equivalent so we can check whether we should throw an
exception.

If we still need a Status type then we should probably just rename it to
avoid the clash, and put a code comment next to it explaining why. For
instance, we could call it ErrorStatus, or just use the original
CairoStatus type without a typedef.

I would like to hide all cairo headers form our cairomm headers at some
time in the future. It's annoying to copy/paste the enum definitions but
this has worked successfully in gtkmm, though we automate it via a (not
really reusable) script that we rerun occassionally.  
  
>   (Currently the Status
> type is exposed as a return type for the functions
> Surface::write_to_png() and Surface::write_to_png_stream() but I
> believe those were implemented by me and maybe should be changed?)\\

Yes. 

>   I
> recall some debate in the past about making the use of exceptions
> optional, but don't remember what the outcome of that discussion was. 
> If it isn't exposed in the API, I guess changing the name of the type
> in cairmm isn't as big of a deal -- any thoughts?

I have no plans to make exceptions optional. I see no sensible way to do
it, and I don't think it's going to have a significant effect on
performance.

-- 
Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com