English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: [Caml-list] Physical counterpart to Pervasives.compare?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-08-24 (12:32)
From: Pascal Cuoq <Pascal.Cuoq@c...>
Subject: Re: [Caml-list] Physical counterpart to Pervasives.compare?
Pascal Cuoq a écrit :
>> Elnatan Reisner wrote:
>>> Is there something that can complete this analogy:
>>> (=) is to (==) as Pervasives.compare is to ___?
> The simple solution is to number at creation the objects that you  
> want to
> physically compare, using an additional field.

Since people are still participating in this topic,
I have a remark. It is more a "what not to do" kind of
remark, but after replying last time, I remembered
that the current algorithm used by OCaml's GC
for compaction does not change the order of blocks
in memory (byterun/compact.c). Therefore, with the
current version, if you make sure in some way
that the values that you want to compare
are allocated directly in the major heap
(there are a couple of ways to do that),
you can theoretically compare their addresses
as unsigned longs: their order will not change
during execution.
But you should still do the comparison
with a unique C function written for this purpose.
If you tried to use a "convert address to int" function,
you would have a race condition between the conversion
of each address and garbage collection.

This is all in very poor taste, even more so than
the usual discussions about == on this list.
Do I get some kind of prize for breaking the record?

PS: I wrote a "convert address to int" function for
another purpose once. In order to increase my chances
for the prize, I will provide it here. Someone might be
interested in it. Perhaps someone who maintains a small
library for computing the size of an ML value...

external address_of_value: 'a -> int = "address_of_value"

value address_of_value(value v)
   return (Val_long(((unsigned long)v)/sizeof(long)));