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 QAA13294; Sat, 31 Jul 2004 16:23:26 +0200 (MET DST) 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 QAA12257 for ; Sat, 31 Jul 2004 16:23:25 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i6VENNSH019051 for ; Sat, 31 Jul 2004 16:23:24 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i6VEMpo24379; Sat, 31 Jul 2004 09:22:51 -0500 (CDT) Date: Sat, 31 Jul 2004 09:31:01 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Markus Mottl cc: Jean-Marie Gaillourdert , Subject: Re: [Caml-list] const equivalent for mutable types? In-Reply-To: <20040731105002.GB11964@fichte.ai.univie.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 410BAB5B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 const:01 jean-marie:99 overwrite:01 read-only:01 violate:01 bug:01 const:01 ignoring:01 pointers:01 pound:99 committing:99 citeseer:01 mutable:01 mutable:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 31 Jul 2004, Markus Mottl wrote: > On Sat, 31 Jul 2004, Jean-Marie Gaillourdert wrote: > > There is a very simple way to do so: Just don't pass the references > > around. > > For references this is certainly usually the preferred case, but for > mutable records this would be plain awkward. You don't always want to > copy all data in a structure to an otherwise equivalent constant record. > > Even in the case of references you might have a SE-problem: what do > you do if you suddenly discover that it is necessary to overwrite a > reference in a large function which only used the plain value before? > This might require tons of changes. If you want to deliberately leave > this option open, just pass the reference with an additional "read-only" > type constraint. > This way lies hell. The problem is that if the called function *can* modify the argument, there is an extra, uncheckable, dependency between the caller and called functions. The depedency can work in both ways- with the caller depending on the called function changing the argument in some known way, or with the caller depending upon the called function not changing the argument. If you violate these constraints, you can easily wind up with a bug. Another thing to note: const in C/C++ isn't. I can always type cast around the const and modify the memory anyways. Even ignoring wild pointers. Worrying about how long it takes to allocate a new structure is being pennywise and pound foolish- and committing premature optimization. Especially considering you're most likely copying from L1 cache back to L1 cache, which is real cheap. Copying a small (3-8 element) structure from L1 cache to a different place in L1 cache is 10-20 clock cycles. A single cache miss that goes to main memory is 100-350 clock cycles. Which means I can copy that structure 5-35 times in the time it takes me to just load it the first time. Take a gander at: http://citeseer.ist.psu.edu/goncalves95cache.html First, get your program working. Then measure it, and see if it's fast enough. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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