[Fwd: Re: [cairo] Missing const in cairo API ?]

[Carl Worth]

On Tue, 03 Oct 2006 00:05:26 +0200, Damien Carbonne wrote:
> In conclusion, do I understand correctly if I must consider that all
> Cairo opaque types may possibly be modified by any function ?

I don't think that's a well-defined question. The objects are opaque
so how can you know anything about whether they are modified or not?
Particularly as far as the C const keyword is concerned, I don't see
any guarantee that could exist here.

For all you know, the cairo objects of interest are constant, but
there is an association between them and some non-const internal
objects, (this is not the case currently, but it's not impossible
given the current API). In a crazy scheme like that, cairo's
implementation could satisfy "const" all over the place but still not
provide functional semantics of an unchanging object.

So what practical value could come from putting "const" there?

Now, there are notions of modifying a cairo object and functions that
do not modify cairo objects, (such as the get functions). And there
are also objects that are non-modifiable (such as the
cairo_scaled_font_t and cairo_font_face_t objects). These notions are
important, particularly for users of cairo objects from multiple
threads. For example, one should never modify an object in one thread
while the object might be read from another. Also, the font objects
are currently cached and shared among threads due to their
immutability, (though see an existing, open problem report on the
mailing list about the mutability of their reference counts).

So, there are these issues, but I think the answer for getting them
right is in the documentation. It might make sense to use "const" as a
piece of that documentation, but that's all it would be. And it
wouldn't be complete documentation, (the notions about threads and
locking will still need to be explained separately), so I don't see
why it would make sense to put it there at all, (particularly as we'd
be doomed to almost always have the const-sprinkling be incomplete
since there would be no checking of it).

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061002/ca9f2db0/attachment.pgp