Re: GError

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> one last note on new/free/create/etc...
> 
> i have a strong association with alloc() in terms of free(), like
> probably most C programmers (if you are a C programmer and you don't
> feel like this, look behind you, you're leaking as hell ;).
> and once you've been exposed to c++ or similar languages, you better
> keep in mind to "delete" "new"ed structures, instead of "free"ing them,
> which is why i don't like new+free very much. so do:
> 
>   new + destroy	or
>   new + ref + unref or
>   alloc + free

This doesn't hold water at all for me. 

There are already new() + free() combinations in GLib/GTK+, you accept
new() + destroy() / new + unref(), which you can't do in C+++.

alloc() simply is not a good name for me ... we've used it in
places in GTK+ where you are allocating raw memory in some sense -
g_list_alloc(), _gdk_window_alloc() [ the latter is now gone. ]

We should standardize on new() + free(). The fact that C++ doesn't
use those names is pretty irrelevant. new() + destroy() is just
too confusing, considering the fact that gtk_object_destroy()
doesn't free memory.

> when it comes to automatic allocations on the stack, sometimes
> in combination with _init, i.e.
>   
>   GError error = { 0, }; or
>   GError error = G_ERROR_INIT; or
>   GError error; g_error_init (&error);
> 
> i won't mix that with any of the above destroy/unref/free, rather,
> structures that got simply _initialized_, with their allocation
> pattern being _opaque_ (or _automatic_) to the programmer, should
> obviously get _uninitialized_ and be release _opaquely_ (or
> _automatic_) as well:
> 
>   g_error_unset (&error); or
>   g_error_free_contents (&error); or
>   g_error_uninit (&error);
> 
> though _free_contents() is somewhat lengthy, and _uninit() doesn't
> feel like a real word (i'm only german though), so i usually use
> _unset().

_clear() is the right name here. But I'm not sure what the advantage
of having on the stack is ... it doesn't save you from having to
free the error.

Regards,
                                        Owen