RFC: do we want/need the "Ptr" typedefs for internal code ?

[Ján Tomko]

On a Tuesday in 2021, Daniel P. Berrangé wrote:
>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.
>

Optimizing for reading speed is more important. So one more reason
to get rid of this "obfuscation".

But even for writing, I've had trouble getting coccinelle to
understand some 'Ptr's, so I had to resort to slower alternatives.

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210309/aa208835/attachment-0001.sig>