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: Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: attrhash
From: Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: 15 Jan 2001 02:23:36 +0100

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?

> 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?

> 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.

> I suggest renaming attrhash to cliattrib, to better indicate the
> usage and purpose, and hide the implementation.

I agree.

(BTW, Brian, could you please wrap your lines at column 72?)

        Falk




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