Complete.Org: Mailing Lists: Archives: freeciv-ai: May 2002:
[freeciv-ai] Re: [Freeciv-Dev] Re: [RFC] Path finding interface #9

[freeciv-ai] Re: [Freeciv-Dev] Re: [RFC] Path finding interface #9

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Per I Mathisen <per@xxxxxxxxxxx>
Cc: freeciv development list <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: [Freeciv-Dev] Re: [RFC] Path finding interface #9
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Tue, 28 May 2002 08:49:34 +0200

On Sun, May 26, 2002 at 06:14:15PM +0200, Per I Mathisen wrote:
> On Sat, 25 May 2002, Raimar Falke wrote:
> > > Also, even though this is a more dangerous way to code, please make these
> > > functions give pointers to allocated structures as return values instead
> > > of passing pointers to existing structures by reference.
> >
> > No. Either the pf_* functions allocate the space (and the callers
> > frees it. This malloc/free is unnecessary and will eat CPU cycles) or
> > the pf_* functions have static variables (which we want to avoid too
> > since. Look at the current warmap code).
> Yes, I want the pf_* functions to allocate the space. It won't eat much
> CPU cycles compared to what else goes on in these functions, but it makes
> the code much more readable.

Can you provide numbers?

> > > ie
> > >   struct pf_path path;
> > >   ...
> > >   pf_get_path(map,x,y,path);
> > >   ...
> > >   pf_get_path(map,x,y,path);
> >
> > So what? path will deallocated if we leave to scope.
> That is beside the point. By looking at the above code alone, you cannot
> tell that 1) "path" is changed in pf_get_path, and 2) the contents of
> "path" passed to pf_get_path is irrelevant.
> If you do
>       path = pf_get_path(map,x,y);
> these two points are apparent from a quick reading of the code.

I disagree. I know at least another function which does it this way:
attribute_get. Also note that dynamic allocation isn't this much used
in the code (see all the foo[MAX_BAR] fields). Why? Because with
static allocation you can avoid a lot of problems you have with
dynamic allocation while you pay with a small amount of extra memory
which isn't used. If you can define reasonably max sizes than this
memory waste is minimal.


 email: rf13@xxxxxxxxxxxxxxxxx
 "I do feel kind of sorry for Microsoft. Their attornies and marketing
  force must have tons of ulcers trying to figure out how to beat (not
  just co-exist with) a product that has no clearly defined (read
  suable) human owner, and that changes on an hourly basis like the
  sea changes the layout of the sand on a beach. Severely tough to
  fight something like that."
    -- David D.W. Downey at linux-kernel

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