Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2005:
[Freeciv-Dev] Re: (PR#13474) a city_production struct
Home

[Freeciv-Dev] Re: (PR#13474) a city_production struct

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: [Freeciv-Dev] Re: (PR#13474) a city_production struct
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 14 Jul 2005 18:30:14 -0700
Reply-to: bugs@xxxxxxxxxxx

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

Benoit Hudson wrote:
> <URL: http://bugs.freeciv.org/Ticket/Display.html?id=13474 >
> 
> I was thinking of doing this patch at some point but never got around
> to it.  It seems like we'd want to have a struct {
>     bool is_unit;
>     building_type_id building;
>     unit_type_id unit;
> };
> for better debugging.  Whichever field is not set should be X_LAST. 
> This would better catch bugs where someone forgets to check is_unit.

Sure, that's fine too.  Only problem is it is not typesafe (if you mix
building and unit in the code you might get a crash but you won't get a
compile error) and it'll take a lot more work to make the change.

I'd rather have

struct {
  bool is_unit
  struct impr_type *building;
  struct unit_type *unit;
};

which is typesafe but will take as much or more work to change.  However
I was planning on waiting for further changes on this until after
pointers are used elsewhere for buildings and units.  But it could be
done first too.

My other question is if this struct can be used inside or merged with
ai_choice.  But I have little idea how ai_choice works.

In summary I don't want to commit myself to too much work here until
it's more clear what the ultimate design should be.  The current patch
is just search-and-replace and only took a couple minutes to make.

-jason





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