Code review comment for lp:~pete-woods/unity-api/add-glib-assigner-class

Revision history for this message
Pete Woods (pete-woods) wrote :

I've put together the sort of thing I was talking about now. This includes the same sort of thing for both char array stuff and GObject instances.

If you can figure out a way to do the Glib side with derived templates I'm all ears. I struggled very muchly with the template instantiation order learning some new things on the way when I just tried to make the GlibAssigner a template instead of macro funkiness.

In terms of the deletion being surprising, let's give an example, assuming we've got a wrapper type that auto converts to **:

void do_stuff(Thingy** t) {}

auto t = unique_glib(new_thingy());
do_stuff(t);
// t is now empty!

I don't like that, and it really does feel like the same problem as the old auto_ptrs:

void do_stuff(auto_ptr<Thingy> t) {}

auto_ptr<Thingy> t(new Thingy());
do_stuff(t);
// t is now empty!

I also don't think you're putting across a concrete argument about why the "Assigners" are bad. Is it just because there's more typing? Can you express more clearly what the problem is, please.

I prefer them because the "wacky types that do magic stuff" only live very briefly for the duration of a function call. Instead of having smart pointers with unusual properties that live potentially a long time.

« Back to merge proposal