[Spice-devel] typedefs and header dependencies

[Uri Lublin]

On 05/24/2016 12:19 AM, 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.
>
> 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...
>
> 3. continue with the fragile approach we now have
>
> 4. use C++ :D
>
> 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.


Hi,

I vote #3.
Recently many lines of code are moving between files, but there
should not be small amount of such moves once the refactoring
is completed, and with option 3 the resulting code would
be easier to read.

Regards,
     Uri.