From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA27593; Tue, 23 Mar 2004 01:00:04 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA09983 for ; Tue, 23 Mar 2004 01:00:03 +0100 (MET) Received: from hirsch.in-berlin.de (hirsch.in-berlin.de [192.109.42.6]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2N002Hd018822 for ; Tue, 23 Mar 2004 01:00:02 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from hirsch.in-berlin.de (localhost [127.0.0.1]) by hirsch.in-berlin.de (8.12.11/8.12.11/Debian-3) with ESMTP id i2N001Ku001717 for ; Tue, 23 Mar 2004 01:00:01 +0100 Received: from first.UUCP (uucp@localhost) by hirsch.in-berlin.de (8.12.11/8.12.11/Debian-3) with UUCP id i2MNo2rp000885 for inria.fr!caml-list; Tue, 23 Mar 2004 00:50:02 +0100 Received: by first.in-berlin.de via sendmail from stdin id (Debian Smail3.2.0.114) Tue, 23 Mar 2004 00:44:15 +0100 (CET) From: oliver@first.in-berlin.de (Oliver Bandel) Date: Tue, 23 Mar 2004 00:44:15 +0100 To: caml-list@inria.fr Subject: Re: [Caml-list] Hashtbl and destructive operations on keys Message-ID: <20040322234415.GA1126@first.in-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; oliver:01 in-berlin:01 oliver:01 bandel:01 caml-list:01 hashtbl:01 2004:99 hashtbl:01 hash:01 val:01 overwritten:01 induce:99 consing:01 overwritten:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 311 On Mon, Mar 22, 2004 at 07:16:57PM +0100, Thomas Fischbacher wrote: > > Dear ocaml hackers, > > I read the documentation in such a way that I must not assume that after > doing a Hashtbl.replace hash key new_val, I can destructively modify key > with impunity. (I do cons a new key at every Hashtbl.add.) When you modify the key, you will have the problem not to get directly to your data (your hash-value). But with Hashtbl.fold you can find anything in the hashtbl, that was not destrctively overwritten. So, if you throw away your key (why should one do that?), you can find your value nevertheless with Hashtbl.fold. > > On the other hand (I have not looked into the sources), I am quite > confident that the system _could_ give me the guarantee that > nothing evil happens if I do so, and especially for the application I am > presently working on, this would induce a noticeable performance gain, > due to reduced consing. (And performance is important here!) You mean that the key is overwritten in-place, because these imperative features are fast?! > > So, could I please get this officially sanctioned? :-) Again: When you throw away your key, you will not have _direct_ access to your value. So if you need that direct access, you have a problem. If it is not necessary to get directly to that data and you are happy with finding the key-value pairs after you have inserted all stuff into the hashtbl, then you can throw away your key, if you want to. Ciao, Oliver ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners