Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2001:
[Freeciv-Dev] Re: attrhash
Home

[Freeciv-Dev] Re: attrhash

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>
Cc: Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: attrhash
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 15 Jan 2001 12:52:08 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxxxx

On Mon, Jan 15, 2001 at 02:23:36AM +0100, Falk Hueffner wrote:
> Brian Olson <locke@xxxxxxx> writes:
> 
> > On Sunday, January 14, 2001, at 07:33 AM, Falk Hueffner wrote:
> > 
> > > I have an alternate implementation, which I think is easier. I
> > > haven't even tried compiling it, but it is just to demonstrate the
> > > concept...
> > 
> > I see potential ambiguity about what part of the code owns the
> > memory submitted to this version. While slightly inefficient,
> > copying leaves no such ambiguity.
> 
> Hm, I thought my implementation did copy the data on inserting. If you
> meant copying on access, I don't see any reason to do so, you wouldn't
> want to modify the data anyway, or did I miss anything?

Who owns the memory? In most cases IMHO the caller would have the
memory allocated anyway:
 struct someData{int foobar;char blub;};

 void think_hard_about_unit(int unit_id)
 {
   struct someData data;

   if(!unit_get_attr(unit_id, MY_SUB_KEY, &data, sizeof(data))
   {
     /* handle unset values */
     data.foobar=12;
     ...
   }
   /* main part */
   ....
   unit_set_attr(unit_id, MY_SUB_KEY, &data, sizeof(data));
 }

> 
> > Also, it may be a benefit or convenience to have calls that behave
> > almost like read() and write(). These calls don't have the subkey
> > that Raimar wanted, too.
> 
> Hm, seems I missed something, what are those subkeys for?

Different agents want to attach different kind of information to
objects. So each agent gets one or more subkeys. I have to admit
subkey is a very good name.

> > I let my keys grow to 3 full ints because it was still easy to
> > compare and hash into the number of buckets. Compressing into 32
> > bits may result in unexpected limits. Choosing the packing creates
> > the limits, 4 bits of type, 12 bits subkey, 16 bits unit? Which of
> > these may run out in the future first? Much safer to use two ints or
> > more.
> 
> I thought there wouldn't be more than 256 different attribute types
> too soon, and 24 bit would suffice for unit ID/tile coord.

Why should we limit outself if hashing a larger block than an int
isn't a problem. AFAIK the current limitation of 32 nations is because
of such self limitations.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Programming today is a race between software engineers striving to
  build bigger and better idiot-proof programs, and the Universe trying
  to produce bigger and better idiots. So far, the Universe is winning."
    -- Rich Cook



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