[cairo] const-ness fixes for transform_distance and
otaylor at redhat.com
Mon May 9 10:26:37 PDT 2005
On Mon, 2005-05-09 at 10:07 -0700, Keith Packard wrote:
> On Mon, 2005-05-09 at 13:06 -0400, Owen Taylor wrote:
> > This does muddle the "plain structure returns are out-parameters"
> > rule that I documented in the language binding appendix.
> And what about the re-entrancy issues of returning a pointer to static
cairo_surface_t *cairo_get_target (cairo_t *cr);
is returning a pointer to non-referenced data, so that already prevents
us from enabling simultaneous access to the same cairo_t from
Returning a pointer to *global* static data is clearly evil.
(Not to argue against myself, just to clarify the situation)
> The C library suffers greatly from this in a number of APIs.
> Passing in a pointer to thread-specific data makes this all much
> > void
> > cairo_get_matrix (cairo_t *cr, cairo_matrix_t *matrix);
> I have a strange though here -- we could mark the cairo calls which do
> not change the state of the library by annotating the cairo_t* with
> 'const'. Would this be a good idea? Or would it only clutter the
> headers? I'm not certain myself, but wanted to increase list traffic
> with side discussions.
IMO, just clutter. You start getting into corner cases pretty
quickly. (Does cairo_reference() change its argument or not?
Does cairo_set_source() change its argument or not?)
The GTK+ is that we never use const on refcounted structures.
It's more an empirical rule than a theoretical one, but it
seems to work out OK in practice.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050509/3981b869/attachment.pgp
More information about the cairo