[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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