[Spice-devel] typedefs and header dependencies

[Pavel Grunt]

Hi,

On Mon, 2016-05-23 at 16:19 -0500, Jonathon Jongsma wrote:
> On Mon, 2016-05-23 at 15:17 -0500, Jonathon Jongsma wrote:
> > On Sun, 2016-05-22 at 04:19 -0400, Frediano Ziglio wrote:
> > 
> > > >  /* FIXME: move back to display-channel.h (once structs are private) */
> > > >  typedef struct Drawable Drawable;
> > > > -typedef struct DisplayChannelClient DisplayChannelClient;
> > > >  
> > > 
> > > We definitively should consider using struct Xxxx instead of moving
> > > these typedef everytime in order to compile...
> > 
> > Or create a spice-types.h header that contains forward declarations for all
> > structs and include that in every other file. The includes really are quite
> > a
> > tangled mess and it's not an easy problem to unravel. I spent some time
> > trying,
> > but it's very difficult to do in a gradual way. I've resisted doing
> > something
> > like this in the past, but I'm starting to warm up to it...
> > 
> > Jonathon
> 
> 
> So, I chatted (very briefly) with Frediano about this on IRC after sending
> this
> email and I thought we should gauge opinions on options here.
> 
> This typedef stuff really does make refactoring more difficult. When we move
> stuff around, we have to keep adding temporary typedefs to make things
> compile.
> Or we have to remove these typedefs to avoid redefining the same struct
> multiple
> types. So there are several options:
> 
> 1. Use 'struct Foo' throughout the code instead of 'Foo' so that we don't have
> to deal with the typedef mess.

yes, +1
> 
> 2. the approach listed above (a spice-types.h file that simply typedefs all
> structs). This is a bit of a maintenance nightmare and needs to be kept up to
> date and for a lot of types that are relatively self-contained it's not even
> necessary to put them in a global header like this...

I am afraid that would be easy to forget about updating the file
> 
> 3. continue with the fragile approach we now have

I think fragile is too strong word
> 
> 4. use C++ :D

I would wait with this
> 
> Anything else I'm not thinking of? I'd like to hear opinions from as many
> regular contributors as possible so we have a rough consensus, but I'd really
> like to do something about it.

Personally I would go for the first option, but it would be nice to avoid some
mass rename...

Pavel