On Fri, 2018-05-25 at 10:04 +0200, Pavel Hrdina wrote:
On Fri, May 25, 2018 at 09:13:51AM +0200, Andrea Bolognani wrote:
> However, I realize it might not be possible to register free
> functions for a native type without having to introduce something
> like
>
> typedef char * virString;
>
> thus causing massive churn. How does GLib deal with that?
If you would look into GLib documentation you would see that this
design basically copies the one in GLib:
Sorry, I should have looked up the documentation and implementation
before asking silly questions. Guess the morning coffee hadn't quite
kicked in yet :/
GLib libvirt
g_autofree VIR_AUTOFREE
g_autoptr VIR_AUTOPTR
g_auto VIR_AUTOCLEAR
For what it's worth, I think VIR_AUTOCLEAR is a much better name
than g_auto :)
In GLib you are using them like this:
g_autofree char *string = NULL;
g_autoptr(virDomain) dom = NULL;
g_auto(virDomain) dom = { 0 };
So yes it would require to introduce a lot of typedefs for basic types
and that is not worth it.
I'm not sure we would need so many typedefs, but there would
certainly be a lot of churn involved.
Personally, I'm not so sure it wouldn't be worth the effort,
but it's definitely something that we can experiment with it at
a later time instead of holding up what's already a pretty
significant improvement.
In libvirt we would have:
VIR_AUTOFREE char *string = NULL;
VIR_AUTOPTR(virDomainPtr) dom = NULL;
VIR_AUTOCLEAR(virDomain) dom = { 0 };
If you notice the difference, in libvirt we can use virDomainPtr
directly because we have these typedefs, in GLib macro
G_DEFINE_AUTOPTR_CLEANUP_FUNC creates similar typedef.
While I'm not a fan of our *Ptr typedefs in general, I guess this
time I'm glad we have them because VIR_AUTOPTR() doesn't hide the
fact that what you're declaring is a pointer; that is, the macro
argument is also exactly the type of the variable.
--
Andrea Bolognani / Red Hat / Virtualization