[Freeciv-Dev] (PR#11213) Making client headers compatible with C++

["Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=11213 >

> [fbriere@xxxxxxxxxxx - Wed Dec 15 18:30:24 2004]:
> 
> On Wed, Dec 15, 2004 at 09:34:25AM -0800, Vasco Alexandre da Silva
> Costa wrote:
> > As I said before, I'm ok with variable renaming or adding casts to
> void
> > pointers, etc. What I am *not* ok with is adding "#ifdef
> __cplusplus" all over
> > the common code, or other C++ specific features. The common code is
> 100% C
> 
> Please, Vasco, I've only proposed *one* such addition.  Qualifying
> this as "all over" is a tad melodramatic...

One is one too many. Sorry if this sounds like a fundamentalist stance,
but that is my take on the matter.

> Besides:
> 
>   toroia:~# grep -r __cplusplus freeciv | wc -l
>   26
> 
> So, nyah! <g>

These are not part of the freeciv code proper. Most are generated
automake and configure black magic, others are in libintl, which we
include verbatim from an external source. This leaves:
client/gui-gtk/gtkpixcomm.h, client/gui-gtk-2.0/gtkpixcomm.h,
client/gui-sdl/SDL_ttf.h.

The first file is in GTK+ standard coding style. The second file was a
good catch, because GTK+ has replaced that with a standard macro in
version 2.x. The third is copied verbatim from an external source.

We could turn these to freeciv standards, but this would make syncing
with the external sources more difficult. (e.g. the gui-gtk-* files are
more or less taken from GtkPixmap or GtkImage source code).

> I do agree that my patch for #11282 is superficial, and that it might
> be better to "fix" it at the source.  You actually never did reply to
> my last comment on that ticket, but feel free to do so if you're still
> uncomfortable with the original patch.  I'd much rather argue about a
> patch than letting it rot away.

Just do as Jason suggested. Rename the 'cid' type declaration to
something else. Be it 'cid_type', 'Build_Type_id', 'Compound_id', etc. I
have no particular favourite, I will leave this for the native language
speakers.

> (As for casting void pointers, maybe you could convince Jason that
> #11283 is not as evil as he seems to think?)

I'm ok with it because despite being nonsense boilerplate in C, it is
still valid plain C. We often add nonsense boilerplate to silence lint,
so this is not too different for me.

As for convincing other people of this sorry, that is your job. :-)