One of the conventions we have had since the early days of libvirt is
that every struct typedef, has a corresponding "Ptr" typedef too.
For example
typedef struct _virDomainDef virDomainDef;
typedef virDomainDef *virDomainDefPtr;
Periodically someone has questioned what the purpose of these Ptr
typedefs is, and we've not had an compelling answer, other than
that's what we've always done.
There are a few things that make me question the status quo
- If we want a const pointer, we can't use
const virDomainDefPtr def
because that expands to "struct _virDomainDef * const", which
is not what we need semantically. Instead we must write
const virDomainDef *def
It is not at all obvious why these two are different, but
none the less they are, which is confusing to contributors
To me this a compelling reason to consider the "Ptr" typedefs
a waste of time, if not actively harmful.
Please don't suggest adding virDomainDefConstPtr too !
- Writing 'virDomainDefPtr' is actually two characters more
typing than 'virDomainDef *'.
IOW these "Ptr" typedefs aren't saving us time when writing
code.
- This convention of having "Ptr" typedefs is atypical among
C projects I've worked on.
Anything that is peculiar to libvirt is another item that
new contributors need to learn, so has a cost to the
project that must be weighed against its benefit.
We can't do anything about the use "Ptr" in the include/ files because
that is public ABI. We can potentially eliminate "Ptr" types everywhere
else in the codebase, even the src/libvirt*.c files corresponding to
the public includes.
Does anyone have suggestions for how these "Ptr" typedefs are
benefiting libvirt ? Would anyone miss them ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
