From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id AC0CFBC6B for ; Sat, 26 Jan 2008 20:58:25 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEogm0fAbSoIh2dsb2JhbACQKAEBAQgKKZs/ X-IronPort-AV: E=Sophos;i="4.25,255,1199660400"; d="scan'208";a="6608178" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Jan 2008 20:58:27 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m0QJwOwK023663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 26 Jan 2008 20:58:24 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m0QJwOTR023661 for caml-list@yquem.inria.fr; Sat, 26 Jan 2008 20:58:24 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-074-018-147.pools.arcor-ip.net (dslb-088-074-018-147.pools.arcor-ip.net [88.74.18.147]) by webmail.in-berlin.de (IMP) with HTTP for ; Sat, 26 Jan 2008 20:58:24 +0100 Message-ID: <1201377504.479b90e042ab7@webmail.in-berlin.de> Date: Sat, 26 Jan 2008 20:58:24 +0100 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Concatenation of static strings? References: <20080119143259.46752d11.mle+ocaml@mega-nerd.com> <53c655920801190255p71346ac9ka45adf0e1cef2d17@mail.gmail.com> <200801261613.51858.jon@ffconsultancy.com> In-Reply-To: <200801261613.51858.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; bandel:01 in-berlin:01 bug:01 bug:01 literals:01 literals:01 mutable:01 pointer:01 pointer:01 mutable:01 shoes:98 char:01 imho:01 imho:01 wrote:01 Zitat von Jon Harrop : > On Thursday 24 January 2008 23:02:48 Ashish Agarwal wrote: > > I was hoping there would be some follow up discussion on the code > below, > > but haven't seen anything yet. Can someone please clarify why this > is not > > considered a bug (or is it). > > This is not considered a bug. String literals are static but array > literals > are not. ?! > > > Given that s is locally scoped within f, I do not see why f returns > > different answers. > > A static local remains the same between calls (so it is not > thread-safe). [...] To have mutable strings, which means it's imperative, not functional programming, is one thing. To -- in C-langauge terms -- copy the reference, meaning a copy of a char*, which means a pointer, is one thing. So one can use String.copy to have a copy of the data, which is pointed to by the pointer (isntead of only using a pointer-copy). Another thing is, that the local used data is not fresh every time it is used in a newly function call. The copy of the references is fast. To have no newly allocated local data, if this data is a string, IMHO is not so fine. And I see no advantages here. And because it's new to me (nobody is pefect ;-)) I thought this is buggy behaviour. I looked into the reference manual and found nothing on that topic. Such decisions IMHO should be part of the reference manual. The thing we discussed on the Array-comparisons btw should also be mentioned in the manual (I did not looked for it in the manual, possibly it's already there?). > > This has been discussed before several times. The reason given more > making > strings static is performance. [...] I remember several discussions on mutable strings and the string-copy problem, but I do not remember on the problem of the allocation inside functions, which you call static. And this two kinds of discussions are two pairs of shoes! If you have a pointer to theese discussions (on that "static" thing that makes frozen local data even on several function calls) this would be fine. It seems I have missed these discussions. Ciao, Oliver