Re: RFC: glocal - automatically freeing memory when it goes out of scope
- From: Dominic Lachowicz <domlachowicz gmail com>
- To: Mikkel Kamstrup Erlandsen <mikkel kamstrup canonical com>
- Cc: gtk-devel-list <gtk-devel-list gnome org>, Morten Welinder <mortenw gnome org>
- Subject: Re: RFC: glocal - automatically freeing memory when it goes out of scope
- Date: Mon, 21 Nov 2011 10:43:32 -0500
If you want this sort of behavior, use a language like C++ that
supports stack-allocated objects natively. GtkMM and GlibMM already do
this wonderfully. Using a GNU-C ism which probably won't work with
most other C compilers (MSVC, LLVM, ICC, ...) feels wrong to me.
On Mon, Nov 21, 2011 at 10:34 AM, Mikkel Kamstrup Erlandsen
<mikkel kamstrup canonical com> wrote:
> On 11/21/2011 03:45 PM, Morten Welinder wrote:
>>>
>>> if (1)
>>> {
>>> glocal_object GFile *file = g_file_new_for_path ("/tmp");
>>> glocal_string gchar *basename = g_file_get_basename (file);
>>> g_debug ("Basename is '%s'", basename);
>>> // look ma' no leaks!
>>> }
>>
>> This is, of course, cute but I don't think this would actually catch many
>> of the
>> non-trivial leaks that make it into the code base today. Those are
>> typically
>> not scope based -- possibly because the attention span of the average
>> programmer is long enough to cover the writing of a whole function, ;-)
>>
>> The current serious leak cases I see are:
>>
>> * The dispose or finalize method of an object type fails to free some
>> stuff. This is
>> quite common.
>> * Cyclical links. The resulting leaks are typically quite big.
>>
>> A case scope-based destructors would handle is this:
>>
>> * Multiple return statements, typically for error handling, where one or
>> more
>> branches forget to free stuff. Cursory valgrinding doesn't catch this
>> because
>> the code doesn't get exercised.
>>
>> The case isn't uncommon, per se, but programs don't hit the cases often.
>
> This is precisely my motivation for introducing this; ie. not to catch
> leaks, but to tidy the code. Bigger code bases almost always grow functions
> with multiple returns - notably when error handling is introduced. Automatic
> freeing can cut down on that complexity considerably. On less complex
> functions it can still add clarity by making the actual algorithms more
> apparent in between all the g_free()s and g_object_unref()s.
>
> Cheers,
> Mikkel
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
--
"I like to pay taxes. With them, I buy civilization." -- Oliver Wendell Holmes
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]