Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2002:
[Freeciv-Dev] Re: [Patch] Boolean cleanup in ai/
Home

[Freeciv-Dev] Re: [Patch] Boolean cleanup in ai/

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Petr Baudis <pasky@xxxxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Boolean cleanup in ai/
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 19 Feb 2002 21:21:23 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Tue, Feb 19, 2002 at 06:47:57PM +0100, Petr Baudis wrote:
> No general objections to the patch (congrats!); it's mostly ready for commit,
> didn't notice anything really weird. 

> There's one minor global objection - more usage of > 0 instead of !=
> 0, 

Since there are cases where negative values are used (as flag values
for example) I used != 0 if I wasn't sure. > 0 otherwise.

> but I think this should be done rather in local cleanups and the
> current change keeps the behaviour identical.

Ok.

> I really tried to read the whole patch, even when it took about half an hour,
> but I wouldn't like to do this once again. So I highly suggest to divide the
> commit to more stages, committing everything noone objects against now (after
> someone else will have a look at this as well), and include only controverse
> parts in a next patch.

I will split it.

> My only objection and piece of code I don't want inside is the gothere() in
> findvictim(). If it compiles and autogames are identical, I think it can go 
> in.

> > Index: ai/aiunit.c
> > ===================================================================
> > RCS file: /home/freeciv/CVS/freeciv/ai/aiunit.c,v
> > retrieving revision 1.171
> > diff -u -r1.171 aiunit.c
> > --- ai/aiunit.c     2002/02/13 05:55:20     1.171
> > +++ ai/aiunit.c     2002/02/18 20:26:00
> > @@ -816,17 +816,17 @@
> >          }
> >        }
> >        if (map_has_special(x1, y1, S_HUT) && best < 99999 &&
> > -          could_unit_move_to_tile(punit, punit->x, punit->y, x1, y1) &&
> > +          could_unit_move_to_tile(punit, punit->x, punit->y, x1, y1) != 0 
> > &&
> 
> Huh. The tristate it returns has no use anyway; so can't we state this 
> function
> as ZOC-independent and return boolean? Like we did with ai_military_gothere().

The return values is compared against 0 and against 1. So I don't
think it is possible to remove this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The Internet is really just a series of bottlenecks 
  joined by high speed networks."
    -- Sam Wilson


[Prev in Thread] Current Thread [Next in Thread]