[cairo] cairo_current_xxx, reference or not?

[Charles Tuckey]

Although I can write C programs, I am not a C programmer by trade or 
temperment. With that caveat, I suggest that always having the 
programmer destroy a managed object is the best way to go.

The semantics of destroying are straightforward and easy to grasp. If 
you create the object (or ask it to be created) then at some point you 
need to destroy it. Simple. If the API takes care of releasing the 
memory for you, the "never" case, then it is not that simple to hackers 
such as myself. For instance, how do I know when the memory will be 
released? This can be documented for each different function but the 
rules are not likely to be the same for all functions. So now I have to 
remember a bunch of different rules to make sure I don't accidentally 
access released memory.

I realize that asking the programmer to destroy every object sometimes 
means that temporary variables need to be used to hold the object but I 
would be willing to pay this price for a straightforward semantics. I 
have done some programming with SWT which uses the destroy paradigm and 
I found it very intuitive to use.

Another reason to use the destroy method is that it hides underlying 
implementation details in the API. The API is free to use pooling or 
other optimization methods and the user does not need to know or care 
about this. As well, if something else besides just releasing memory 
needs to be done having a destroy method on every object makes this 
invisible to the user as well.

charlie

Carl Worth wrote:
> On Thu, 4 Nov 2004 10:55:58 -0800, Ned Konz wrote:
> 
>>On Thursday 04 November 2004 9:52 am, David Reveman wrote:
>>
>>>With the recent font changes, cairo_current_font returns a cairo_font_t
>>>object that needs to be destroyed. This is different from before and
>>>different from what cairo_current_pattern and
>>>cairo_current_target_surface are doing. If this is the intended
>>>behavior, cairo_current_pattern and cairo_current_target_surface should
>>>probably be modified to return a references instead of just pointers.
>>>It's a bit confusing right now.
> 
> 
> Yes, thanks for bringing this up. I'd been sitting on the cairo_matrix_t
> thread for a couple of months, intending to bring up this same point
> about unifying the semantics across the board. You know helped push me
> into finally replying to that thread.
> 
> 
>>I'd be in favor of having a simple rule: whenever there's a function that 
>>*returns* a pointer to a managed (reference-counted) type, you *always* have 
>>to destroy it.
> 
> 
> Either always or never--there are arguments for both sides, and I don't know which side I come down on just yet.
> 
> But, yes, I do want a single, simple rule. A C API is just too hard to
> use correctly otherwise.
> 
> -Carl
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>