Version française
Home     About     Download     Resources     Contact us    
Browse thread
surprised by string_of_bool
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David Allsopp <dra-news@m...>
Subject: RE: [Caml-list] surprised by string_of_bool
> Perhaps this has been discussed before, but I found this to be disturbing.
http://caml.inria.fr/pub/ml-archives/caml-list/2007/06/bfd46e630ef150536b616
debe927384b.en.html on this and also
http://caml.inria.fr/pub/ml-archives/caml-list/2006/05/8158dd9e9581137f4bbcb
551e3ca6f3e.en.html on immutable strings in ocaml.

> It seems easy enough to fix this problem, so that, for example,
> print_string (string_of_bool true) always does the same thing.
It depends on whether you regard it as a problem! IMHO if you write code
that uses string mutation then you should be fully aware of where the
allocation of the string that you're altering took place, just as you would
with a buffer in C. If you're writing a library and are paranoid about
string literals being altered then you just have to String.copy everything
(I've used that before e.g. for the ocaml FFI in an ocaml-based interpreter
for a language that has immutable strings only).

The cost of having literal values freshly allocated on each function call
(i.e. inserting String.copy before every non-format string literal) is a
painful penalty for functional code that doesn't mutate strings.

> The "correct" strategy seems to be used for string_of_float infinity:
Well, it's just that string_of_bool can only return two possible values
where string_of_float must perform an allocation each time. The declaration
let string_of_bool x = String.copy (string_of_bool x);; would "fix" this
function for you.


David