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

[Damien Carbonne]

Carl Worth a écrit :
> 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?
>   
I understand opaque as private. If this is correct, it is only related 
to implementation hiding.
 From the specification viewpoint, thinking of opaque/private types as 
ADT, it is perfectly possible to define, in the contract (API), the 
possible "user visible" effects that any function may have on the object.
If I say that an object can not be modified by a function, it only means 
that I tell the compiler that it can make the assumption that the result 
of this function only depends on the values of its input parameters. 
This assumption is still true if I use a cache. The compiler may be 
unable to check this assumption (usage of pointers, ...). Of course 
there is no guarantee on timing. And regarding thread safety, it is 
another issue.
I understand and know that, in C, const can be easily cast away, so that 
its usefulness may be small.
However, I think it is possible to write C/C++ code that use const and, 
at the same time, follows what I try to explain.
This means that one must be careful not to use const cast and be very 
careful with aliasing (at least).

I also know that languages like Java are close to what you are trying 
(?) to explain. One must not make any assumption on the effect of a 
function on an object. This is another possible viewpoint.

Anyway, my intent is not to force anybody to change cairo API - unless 
there is an error ;-)
If I try to create an Ada binding, it's because I find this library 
quite interesting, useful and of quality.
I simply want to understand. For that, I have read cairo documentation, 
its source code and another binding code.
But this may be insufficient. For example, it's not because current 
implementation of cairo_status has no "user visible" side effect (as 
defined before), that it will never have. Simply because there is no const.
So my initial question was only about identification of those "user 
visible" side effects.

> 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.
>
>   
This is precisely this functional semantic I try to identify !
> 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
>   

I agree that a compiler can hardly check an ADT contract when internal 
pointers are used.
Is it because such checks can be guaranteed with simple structures 
(e.g., cairo_matrix, ...) that const is used with them ?

Damien