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

["Frédéric Brière" <fbriere@xxxxxxxxxxx>]

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

On Tue, Nov 30, 2004 at 02:01:18AM -0800, Jason Short wrote:
> You cast a void pointer as a SPECLIST_TYPE one.  C allows implicit 
> conversion from void pointers, to...prevent bad surprises.

I think it's more a question of syntactic sugar. <g>

> Forcing a cast is annoying but not fatal.  But it's best to avoid
> where possible. 

I just want to make sure you know that I didn't "force" anything; there
was already a cast involved, and I merely made it explicit.

As for whether or not casts should be left implicit or made explicit, I
suppose it's one of those Emacs/vi things that people can argue over for
years.  (Me, I'm a Perl zealot, so I really don't have an opinion on the
matter.)

> The last time someone started writing a C++ client I believe all sorts 
> of code got changed for the worse.  But from what you say it seems only 
> the headers need changing.  Can we make only the headers (.h files) C++ 
> compatible, and allow C++ clients to be compiled?  If so that should be 

That's what I'm striving for.

Understand that, as long as two object files agree on function names and
argument size/representation, it doesn't matter how they were coded to
the linker.  With C and C++, extern "C" takes care of the former, and
the use of identical basic types, the latter.  (The exception being that
in C++, sizeof(enum) <= sizeof(int), whereas they're equal in C.
However, g++ doesn't take advantage of this by default.)

For fun, I've just written a dummy program that includes as many headers
as possible -- everything but amiga, intl, server[*], utility/ftwl,
speclist.h, specvec.h, ai/ailog.h[**] and common/packets_gen.h[***] --
and it compiled fine as C and C++.

 [*]  There were too many conflicts between client and server functions
 [**]  It includes server/gotohand.h 
 [***]  Already included by packets.h, can't be double-included


Aside from the stuff I've already filed, I only have one issue left: a
one-line change in shared.h that's right on the tail of my first stdbool
patch.  (I'm waiting for the first patch to go through before I submit
another.)  Everything else looks fine.


> You should provide patches for each element one at a time so we can 
> discuss them.  I believe there's already a patch for stdbool in RT 

Sorry for the big ticket; I feared filing several small tickets on the
same issue might have been seen as annoying.  I'll split it up and open
three new tickets.  Will you still apply the patch attached to the
original ticket?

As for further patches, as I said, the rest of the ticket requires some
decisions or choices to be made, so I sought your guidance.  I'll try to
be clearer in the offspring tickets.  (When it's only a naming issue,
would you rather I submit a patch with a dummy name, which you could
edit before applying?)


-- 
             Frédéric Brière    <*>    fbriere@xxxxxxxxxxx

 =>  <fbriere@xxxxxxxxxx> IS NO MORE:  <http://www.abacomsucks.com>  <=