(by request of Lars): “This is a public service announcement.”
For some time, GCC has had support for __attribute__((cleanup)) which is a really nice way for automatically cleaning up variables when they go out of scope.
After a few attempts at people suggesting it for GLib, Alex finally convinced me to give it another thought. We originally resisted calls to implement it on the basis of portability, but having it in libgsystem (which has provided wrappers for a while) has shown it to be extremely useful and very popular. I came up with a pretty nice basic API concept and we iterated on it during the Developer Experience Hackfest that Collabora just hosted in Cambridge.
The changes just landed in GLib.
These macros only work with GCC and clang, which means that you should not use them on programs that you want to be buildable by MSVC (or other compilers).
The new API is best explained with an example:
{
g_autoptr(GObject) object;
g_autoptr(gchar) tmp;
g_auto(GQueue) queue;
g_queue_init (&queue);
object = g_object_new (...);
tmp = g_strdup_printf (...);
// no free required
}
In order to support this for your types, you need to make use of the G_DEFINE_AUTOPTR_CLEANUP_FUNC and related macros. This will happen automatically if you make use of the new G_DECLARE_DERIVABLE_TYPE or G_DECLARE_FINAL_TYPE macros.
Please use responsibly.
A few interesting caveats with these:
Unless there’s some non-obvious magic going on here, you need to initialize these pointers to NULL; otherwise if you leave the function before initializing them the attempt to free them will go horribly wrong.
If you want one of these items to survive the function, such as if you finish initializing something and want to add it to a long-lived data structure that will take ownership of it, you need to set the local pointer back to NULL so it doesn’t get freed.
Cool, so GLib really is like C++ now. Just way much more verbose. :-)
So let me get this straight. Instead of the obvious free/unref calls, I now surround my declarations by weird looking and cryptic marco calls? What exactly is the benefit to me as an app developer of this?
I’ve been using this the last couple of days, and it’s quite honestly the best middle ground I’ve seen between GObject and moving to C++. Combined with G_DECLARE_*_TYPE(), my headers are actually smaller than C++ classes, but with the benefit of 1) no name mangling 2) free language bindings.
It takes about 10 minutes to get used to the “g_autoptr(foo)” stuff, and then its not a big deal.
I’ve basically removed all of my “goto error;” handling.
If you need MSVC support, clearly you shouldn’t be using this yet. My hope is that the clang interop with MSVC will help make that a non-issue before long.
XlC might actually support it with recent versions. They are pretty good about tracking GCC frontend features. I doubt suncc will get to it though.