Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] const equivalent for mutable types?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-07-31 (14:23)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] const equivalent for mutable types?
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 

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:

First, get your program working.  Then measure it, and see if it's fast 

"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 

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: