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: Brian Olson <locke@xxxxxxx>
Cc: Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>, Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: attrhash
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 14 Jan 2001 22:31:47 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxxxx

On Sun, Jan 14, 2001 at 01:47:09PM -0700, Brian Olson wrote:
> 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. Also, it may be a benefit or

Agreed.

> these may run out in the future first? Much safer to use two ints or
> more.

Agreed.

> Of course send to server has to either be built in just before the

"built in" into what? common/hash.c?

> call to the hash.c call, or for block send, enumeration will have to
> be added to the common/hash.c code.

Yes.

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

If cliattrib stands for client attributes why not just call it
client/attributes.[ch]? Since the server methods will be small and
referenced from player they can be put into server/plrhand.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "If at first you don't succeed... well so much for skydiving."



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