Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: PATCH: map iteration (PR#1018)
Home

[Freeciv-Dev] Re: PATCH: map iteration (PR#1018)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: jdorje@xxxxxxxxxxxxxxxxxxxxx, freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: PATCH: map iteration (PR#1018)
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 29 Oct 2001 00:34:17 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sun, Oct 28, 2001 at 04:06:15PM -0400, Ross W. Wetmore wrote:
> At 10:54 AM 01/10/24 +0200, Raimar Falke wrote:
> >On Tue, Oct 23, 2001 at 09:24:00PM -0400, Ross W. Wetmore wrote:
> >> Whole_map_iterate() currently *guarantees* the map positions are all
> >> not only real, but normalized ... no checks are needed until you start
> >> to add new map types. I think Raimar just got carried away in his
> >> enthusiasm to bog doen the code with checks here.
> >
> >All this stuff Justin is thinking about is preparation work for other
> >map types. This will reduce the size of the final patch which adds
> >other topologies.
> 
> As far as I am aware, no other topology currently under consideration
> needs these checks. The loop constraints are sufficient. So save this
> baggage until it is needed, though leaving it in the MACRO in comments
> is a trivial way to keep everyone happy.

We are still talking about a check for whole_map_iterate? IMHO this is
needed for every topology which doesn't has unreal map positions in
[0..map.xsize[ X [0..map.ysize[.

> >> >My understanding is that whole_map_iterate also doesn't guarantee
> >> >anything about the order in which the coordinates are traversed.  The
> >> >stuff in server/savegame.c certainly needs such a guarantee.
> >> 
> >> This is true, but it is easily remedied by making a fixed order part of
> >> the interface, or providing versions that do have fixed orders.
> >
> >It may be nice to have macros for this but I see for example no point
> >in providing a macro which is used two times in savegame.c. So we have
> >to do some kind of requirement analysis.
> 
> Adding one or two extra macros like this is really not that significant
> in terms of code bloat. Adding a comment to point one at the location
> that really needs this special flavour is also a useful documentation
> technique for someone that decides they need the same flavour and then
> rolls their own when they see that the general macro is insufficient.

> To put it bluntly, it is not the current use, but the future abuse that
> you are fixing :-).

Yes this may be correct.

> Anyway, I presume that savegame really only needs it for backwards
> compatibility with older saved games. Any games written and read back 
> in with any alternate ordering should still work, right?

No. At least I don't want this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "If at first you don't succeed... well so much for skydiving."


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