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.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel