[cairo] API Shakeup: cairo_current_path -> cairo_copy_path_data

mental at rydia.net mental at rydia.net
Fri Mar 11 15:07:01 PST 2005


Quoting Carl Worth <cworth at cworth.org>:

> First, the convention would be to name it something like:
>
> 	cairo_path_data_destroy (cairo_path_data_t *data);
>
> but then we'd have an unconventional "destroy" function with no
> matching "create", (nor "reference").

That doesn't seem quite so bad, though given this is non-refcounted
POD, it might make sense to employ a different convention like
_free instead of _destroy to underscore the distinction.

> Second, the cairo_copy_path_data function returns an array, so we
> open the possibility for the user to call the "destroy" function
> with something besides the address of the first element. There are
> no other allocated array objecte in cairo so far, so there would
> be nothing to indicate to the user that this destroy function must
> only be called on the first element. Meanwhile, the semantics of
> free are well-enough understood to not suffer from this problem.

Hmm.  That would seem to suggest either:

 1) call it cairo_free()

 2) use a structure with an array/pointer element rather than
    a raw array, avoiding ambiguity about what to pass the
    destroy/free fuction

The latter has the advantage that you could also have a "length"
member[1], avoiding all the grief and pain that has been wrought
upon the world by value-terminated C arrays over the years.

-mental

---

[1] i.e. (this would be allocated to size):

  typedef struct {
    unsigned length;
    cairo_path_data_t data[1];
  } cairo_path_t;

 or (if you don't like "magic" array members):

  typedef struct {
    unsigned length;
    cairo_path_data_t *data;
  } cairo_path_t;




More information about the cairo mailing list