Re: g_string_free



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]