[Freeciv-Dev] Re: [Patch] Bool cleanup of client/
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Fri, Mar 15, 2002 at 12:24:12PM -0600, Mike Kaufman wrote:
> On Fri, Mar 15, 2002 at 05:59:56PM +0000, Ben Webb wrote:
> > On Fri, Mar 15, 2002 at 06:41:02PM +0100, Per I. Mathisen wrote:
> > > On Fri, 15 Mar 2002, Raimar Falke wrote:
> > > > - replaces gboolean with bool
> > >
> > > Uh-huh, is this a good idea? If you define bool to a different size than
> > > the gnomes do, won't this possibly cause some very hard to find breakages?
> > It seems strange to me, conceptually, to pass "bool"s to functions
> > that are prototyped to take "gboolean"s.
> especially if those functions passed back something > sizeof(char) to
> signify 1.
As I said we have to distinguish between GTK/GDK/glib boolean and
freeciv boolean. It is for example also possible the gboolean will
change in the future.
> > > So you have settled on char for bool? I think this is a bad idea. Modern
> > > CPUs don't like 8bit types much.
> > In my opinion, if it's really going to make that much difference,
> > the change needs to be tested on as many architectures as possible, since
> > (as I seem to recall being pointed out already) whether "char" is faster
> > than "int" tends to be machine-specific. This would, presumably, require
> > a configure test, and this seems like a lot of work for something with a
> > possibly negligible performance improvement.
> ugh. I should have made my point earlier before Raimar did a lot of work,
> but I'm not so hot on this whole idea. I do like using bool for variables
> and return values and such because it gives immediate feedback to the
> developer what kind of value he should expect, even if the compiler treats
> it no differently than an int (you can also more quickly discern what a
> function is doing); however, what I don't like is the sort of stuff going on
> in options.c for example, where variables are cloned, structs are expanded
> and lots of switch statements, cruft, etc are added for negative tangible
But these infrastructure changes are needed to allow for example
"true"/"false" instead of "1"/"0". Nevertheless it is too late
"If at first you don't succeed... well so much for skydiving."