Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Re: [Patch] Cleanup of units and unittypes (PR#951)
Home

[Freeciv-Dev] Re: [Patch] Cleanup of units and unittypes (PR#951)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [Patch] Cleanup of units and unittypes (PR#951)
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Mon, 10 Sep 2001 22:05:22 -0400

At 03:01 AM 01/09/10 -0700, rf13@xxxxxxxxxxxxxxxxxxxxxx wrote:
>On Mon, Sep 10, 2001 at 02:33:06AM -0400, Ross W. Wetmore wrote:
[...]
>> BTW: what is the real value of getting rid of Unit_Type_ids that seems
>>      to be driving this?
[...]
>3) the "type" field in "struct unit *" may change to "struct unit_type
>   *" in the long run.

If this is the case, then simply using punit->type or acity->type makes 
a lot more sense than unit_type(punit) and city_unit_type(acity), and 
none of this extensive CVS updating is required.

Also, there is a current problem, but it can be solved by a rather
inexpensive id range checking macro.

But with unit_type(punit) being used everywhere unchecked there are 
going to be a lot of code constructs like

  if( punit && unit_type(punit) && unit_type(punit)-><field> == <blort> )

which doubles the function call cost (if the optimizer can't catch it
and as it probably doesn't understand what a function might return this
is quite likely) plus it makes for very unwieldy constructs.

Since the long term goal doesn't need this, is it not better to move
directly to that on a struct by struct basis?

>       Raimar
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "I heard if you play the NT-4.0-CD backwards, you get a satanic message."
> "That's nothing, if you play it forward, it installs NT-4.0"

Cheers,
RossW
=====



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