Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Dominic Lachowicz <domlachowicz gmail com>]

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