[Freeciv-Dev] (PR#13420) RFC: refer to static structures by pointer

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

Some of the groundwork for this has already been done by adding index
values to these structures.  However I said before that I wasn't yet
ready to change to using pointer values for them.

But now I am!  Specifically, any structure that is static (where the
pointer is not going to move and will always be valid) should be
referred to by pointer rather than by index.  This includes terrains,
improvements, techs, nations, unit types, etc.  Notable exceptions are
cities and units: these are not static, they may go away, they're stored
in a hash not an array, and they have an ID not an index.

Note that tiles are already referred to by pointer.  This was a change I
made a good while ago and it's turned out rather well.  Players are also
referred to by pointer (a change made many years ago I believe).

Reasons a pointer is better:

1.  Less code.  Struct-accessing code is reduced by about 10% according
to some patches I've made.

2.  Safer.  It's type-safe and hard to confuse different types of
objects.  Sanity checking is easier because invalid pointers are harder
to make than invalid integers.

3.  Faster.  The difference is probably negligible unless we have some
inefficient accesses in an oft-run inner loop somewhere.  Remember not
to worship the little tin god.

Reasons an integer is better:

1.  Wrappers allow checking of validity.  This is particularly useful
with units and cities (find_unit_by_id is used all over the place to
check if a unit still lives) but shouldn't be an issue for static structs.

2.  Todays static struct may tomorrow be dynamic.  Well, there's already
this danger to some extent since some structs *are* dynamic.  The
map.tiles is an example.  However the struct is fixed over the course of
a game.  Later we might make it possible to add or delete building types
in-game, so you might think a hash would be a better choice.  But I
don't see this as overriding all the advantages, and a simple garbage
collection system would be rather easy to implement for this (we already
support this as some buildings/nations/unittypes are marked "unused").

Anyway, my idea is to start simple: with terrains.  Then move on to
nations, teams, and progressively work up to buildings (which are
probably the biggest).

Also, I still want to rename pplayer->player_no to pplayer->index for
consistency.

-jason