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

> [wsimpson - Lun. Oct. 01 20:55:36 2007]:
> 
> Pepeto _ wrote:
> > 1-Static or dynamics datas?
> > 
> > The most of the main structures (player, connection, advance, ...)
> > except city and unit are declared static (for example
> > game.players[MAX_NUM_PLAYERS + MAX_NUM_BARBARIANS];). Is this a
> > deliberate choice? Maybe it could be a player_list, then there shouldn't
> > have maximum of players. I understand that it was certainly to find
> > player by id faster, but it seems that the unit/city->owner is now a
> > pointer.
> > 
> Apparently, according to comments in the code and the HACKING file,
> everything was once indices, to be compatible with the network code.

My propositions are not for a 2.0, 2.1, 2.2 but for trunk (for a future
release). Making them dynamic would remove the problem of compability
problems, because the server and the client could support resizable lists.

> Gradually, many things have changed to pointers.  Much easier to find
> bad or uninitialized values.  I've recently done this with a lot of
> player, advance, etc.  Look at trunk and 2.2, not 2.1.

Yes, I noticed it, and it is a great thing.

> In my time here, the unit/city->owner has always been a pointer, with
> an accessor function that can more easily be changed.  Making sure
> everything uses the accessor function has been a task I've been doing.

But look at 2.0 code (that I know you don't enjoy so much),
unit/city->owner are player ids.

> There are bit fields for players, so the maximum is fixed.
> 
> There are bit fields for advances, so the maximum is fixed.
> 

Yes, true, I didn't think about it.

> > 2-struct unit
> > 
> > I see numerous ids in this structures. Shouldn't they be replaced by
> > pointers?
> > homecity could be a (struct city *)
> > transported_by could be a (struct unit *)
> > It could be a struct unit_list *transported_units, to find faster and
> > clearer what units are transported. Then occupancy member would be
> > replaced by unit_list_size().
> > 
> There are earlier messages on this topic.  For whatever design reason,
> the unit and city are usually numbers, not pointers.  In the current
> code, units and cities can suddenly disappear.  The code has to check
> whether they still exist every time something is processed.

The idea is not to remove unit ids, but to have direct access to the
unit data. Unit and city id must live, they are the only mean we have to
know if a unit or a city is still alive in the server code, and the only
way to communicate between client and server.

> 
> As for transported_by, there is already a technique for listing the
> transported units, an iterator on the units at a tile.
> 

Yes, but... It would look cleared to have a such list to manage it, to
be sure of the exact number of units in the transporter unit. Or to
iterate faster unit in (which is not a really great argument I agree :D).

> 
> > 3-struct city
> > 
> 
> > struct trade_route {
> >   struct city *city1, *city2;
> >   int value;
> > };
> 
> 
> > enum trade_route_status {
> >   TRADE_ROUTE_PLANNED,
> >   TRADE_ROUTE_IN_ROUTE,
> >   TRADE_ROUTE_IN_ROUTE_AND_PLANNED,
> >   TRADE_ROUTE_ESTABLISHED
> > };
> > 
> Seems like a good idea to me....  But not a high priority.
> 

Like I explain upper, t is just ideas for future, no need hurry :).
There are lot of important tickets still not resolved.


_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to