Re: g_string_free
- From: Darin Adler <darin eazel com>
- To: Michael Meeks <michael helixcode com>
- Cc: <gtk-devel-list redhat com>
- Subject: Re: g_string_free
- Date: Mon, 31 Jul 2000 10:40:48 -0700
on 7/28/00 6:54 PM, Michael Meeks at michael@helixcode.com wrote:
>> That functionality seems to be too much of an exception from normal
>> _free semantics, and on the first glance, the usage appears to be an
>> error. Maybe it should be a new function
> Hmm; but we already have this boolean to g_string_free and everyone
> understands its use;
As someone spending the last few months learning glib and gtk I think the
boolean to g_string_free is one of the more confusing interfaces in glib
(even though it's a tiny minor point). I *hate* functions where you pass a
boolean to make it do two different jobs. I think making a better interface
here would be a nice little improvement.
> I am merely asking for a small feature, that of returning the ->str element
> from the free; most people will never notice the change, there will be no code
> changes required to accomodate it, and I think it will considerably shorten
> and simplify several code paths I have as well as ( perhaps ) saving registers
> on register poor architectures.
Yes, glib could use a function that frees the GString and returns the
pointer. I'd prefer a new function (perhaps we can eventually phase out
g_string_free(FALSE) completely), but adding the return value to
g_string_free would be OK. What I don't like about a return value for
g_string_free is that it confuses the issue even further by introducing the
question of what g_string_free returns when you pass TRUE.
-- Darin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]