Re: gsf api thoughts
- From: Zbigniew Chyla <cyba gnome pl>
- To: gnome-office-list gnome org, abiword-dev abisource com, gnumeric-list gnome org
- Subject: Re: gsf api thoughts
- Date: Fri, 2 Aug 2002 14:14:56 +0200
On Thu, 2002-08-01 at 22:47:28, Jody Goldberg wrote:
> (...)
> 1) gsf_output_printf (and friends)
> On the input side I got a gsf_input_textline class to handle reading
> text sources line by line (1 byte encoding or utf8). That seems
I have no opinions on this but while reading gsf sources I noticed that
the only difference between gsf_input_textline_ascii_gets and
gsf_input_textline_utf8_gets is:
@@ -21,7 +21,7 @@ gsf_input_textline_ascii_gets (GsfInputT
ptr = textline->remainder;
end = ptr + textline->remainder_size;
- for (; ptr < end ; ptr++)
+ for (; ptr < end ; ptr = g_utf8_next_char (ptr))
if (*ptr == '\n' || *ptr == '\r')
break;
All 7-bit characters (including '\n' and '\r') can represent only
themselves in UTF-8 strings (every byte in multibyte sequence has the
highest bit set to 1) so it looks like both functions do he same thing.
I suggest removing gsf_input_textline_utf8_gets.
> 2) output unref vs close. Should unrefing an output close it ?
> I suspect so given that any other behaviour would be much harder to
> implement.
You should never rely on unref being called. What if a reference gets passed
to some garbage collector (eg Python's)? Most GCs don't guarantee that all
unused references will be freed.
I'd rather put something like:
g_assert (gsf_output_is_closed (output))
in finalize method to detect programmers' errors (the death conditon).
Zbigniew
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]