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] Looking for a real array
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-04-28 (16:32)
From: Brian Hurt <brian.hurt@q...>
Subject: Re: [Caml-list] Looking for a real array
On Mon, 28 Apr 2003, Eray Ozkural wrote:

> I knew this all along but looks like I neglected that an array is in fact an 
> array of pointers rather than an array of contiguous storage blocks in 
> memory. Is there a way to get real FORTRAN/C arrays for people who might not 
> want this extra level of indirection?
> val make : int -> 'a -> 'a array
>  Array.make n x returns a fresh array of length n, initialized with x. All the 
> elements of this new array are initially physically equal to x (in the sense 
> of the == predicate). Consequently, if x is mutable, it is shared among all 
> elements of the array, and modifying x through one of the array entries will 
> modify all other entries at the same time. 

If this is a problem, you might want to use Array.init instead.  Instead 
of doing (for instance):
let r = ref 0.0 in Array.make n r
which returns an array of float references, initially all r, so changing 
one changes all of them, instead do:
Array.init n (fun _ -> ref 0.0)
which creates a new reference for every element.

Having a reference in addition to the data structure is a little bit of 
overhead.  But optimization is a tricky thing- often times, what you gain 
in the straights you lose in the curves.  For example, what happens when 
some other peice of code keeps a pointer to a single element of the array, 
when the pointer to the rest of the array- and all the other elements- are 
gone?  In ocaml, the array and all the other elements become garbage, and 
the last, lone object that is not garbage stays around.  Also, copying 
becomes a big issue in my experience.

Personally, I find one extra level of dereferencing isn't that big of a 
deal.  If you're too the point where it is a big deal, you are already 
talking about hand-tuned assembly language.  My advice: stop worrying 
about minutia.  Permature optimization is the root of all evil.


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