qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] Separate function types from opa


From: Greg Kurz
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] Separate function types from opaque types in include/qemu/typedefs.h
Date: Thu, 22 Jun 2017 21:23:32 +0200

On Thu, 22 Jun 2017 19:34:58 +0100
"Dr. David Alan Gilbert" <address@hidden> wrote:

> * Peter Maydell (address@hidden) wrote:
> > On 22 June 2017 at 19:08, Thomas Huth <address@hidden> wrote:  
> > > On 22.06.2017 19:50, Dr. David Alan Gilbert wrote:  
> > >> Could do; I'm just not finding tiny header files with one or
> > >> two entries each that useful.  
> > 
> > Well, it means that the bulk of code that doesn't care about the
> > types doesn't get its compilation fractionally slowed by having
> > to parse the typedef anyway. In general I think we're drifting
> > towards "have each .c file get fewer things automatically" rather
> > than otherwise (eg more finely focused files rather than stuffing
> > everything into qemu-common.h).  
> 
> At the cost of things getting fractionally slower by including lots
> more tiny headers.
> 
> I generally agree in the case where there's a useful chunk,
> but when it's down to one or two definitions I don't see the point.
> 
> > > Do we really need these function typedefs at all? IMHO it's quite ugly
> > > to hide such things in a typedef unless it is really necessary (and in
> > > this case, it does not seem to be really necessary since it is only used
> > > in a few places). So what about simply removing the typedefs in this 
> > > case?  
> > 
> > I find function typedefs much more readable than having the
> > function-types inline in function arguments and the like.
> > 
> > This is all fairly rapidly heading into bikeshed territory
> > though -- in the final analysis I don't think it matters
> > much what we do.  
> 
> Agreed.
> 

Last question for my own comprehension.

I can't think of a case where we would do something like:

   some_vmsd->load_state_old = some_se->ops->load_state;

Does it make sense for VMStateDescription::load_state_old and 
SaveVMHandlers::load_state
to be of the same type ?

> Dave
> 
> > thanks
> > -- PMM  
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK

Attachment: pgpwZxWn833n0.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]