[PartialGestalt]

While working on a screensaver and visualization addon, I noticed that there are a few spots in the header files (xbmc/addons/include/*.h) that assume C++ inclusion. With a little massaging of the headers (but no change to the core), the interfaces themselves seem to be fairly C-friendly, however.

The PVR headers look to be quite a bit trickier to finesse, and would require a breaking change to make C-friendly.

So, a couple of questions:

1. Any objection to a patch to make the screensaver and visualisation headers fully C-friendly?
2. How valuable is it -- in the long run -- to support C-based pvr addons?

(BTW, I'm happy to move this to either or both of the visualizer and screensaver- or pvr-specific boards, but thought it better here since it concerns all three of those addon types.)

[davilla]

I'd be interested in what you found and fixed.

Remember, we are in a release cycle for Frodo and are feature frozen until Frodo is released.

[PartialGestalt]

Well, "fixed" is in the eye of the beholder. Since they seem to be written for C++, and that works just fine, I would call this a feature add for C support rather than a bugfix.

For the screensaver and visualisation headers, it's mostly just making sure that the 'extern "C"' bits are protected with an "#ifdef __cplusplus", with the occasional naked enum or struct declaration changed to be a typedef:

struct LABEL { int example; } -->becomes--> typedef struct { int example; } LABEL;

(which should generate the same code -- I'll check with whatever compilers I can get my hands on to verify).

One of the interfaces is also declared to return a 'bool', which isn't available as a base type for many C compilers, but can be handled with a simple macro (in the same mechanism that some of the C99-supporting compilers use).

The PVR API is a bit trickier, since it passes args by reference for a lot of calls, and C requires an extra level of indirection to accomplish something similar (and switching to ** from *& is a breaking change). (Having said that, though, the C-friendly ** or *** args are used in other APIs, so it wouldn't be out of character).

In any case, it's certainly not a high priority; even if we weren't frozen, this would only affect a subset of addon devs, and they can make the changes locally in the same way that I have. Anything that I'd put in could easily wait until post-Frodo.

The real question behind this thread isn't really the particulars of the change, but rather to get a sense of the team's goals for addon development. Is the intent to support C as well as C++ in general? The references to C-Pluff kind of imply it, but I didn't see on the Wiki where it was explicitly one way or the other.

My $0.02 is that it's worth it to explicitly support C in vis and ss addons (especially since there's a lot of ss and vis code out there in C already), but PVR code is rare (and new) enough that API breakage would make it prohibitive.