From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Concatenation of static strings?
Date: Sat, 26 Jan 2008 20:58:24 +0100 [thread overview]
Message-ID: <1201377504.479b90e042ab7@webmail.in-berlin.de> (raw)
In-Reply-To: <200801261613.51858.jon@ffconsultancy.com>
Zitat von Jon Harrop <jon@ffconsultancy.com>:
> 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
prev parent reply other threads:[~2008-01-26 19:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-19 3:32 Erik de Castro Lopo
2008-01-19 6:50 ` [Caml-list] " David Allsopp
2008-01-19 7:36 ` Erik de Castro Lopo
2008-01-19 10:55 ` David Baelde
2008-01-24 23:02 ` Ashish Agarwal
2008-01-25 1:57 ` Oliver Bandel
2008-01-25 10:47 ` Loup Vaillant
2008-01-26 13:27 ` Ashish Agarwal
2008-01-26 16:13 ` Jon Harrop
2008-01-26 19:58 ` Oliver Bandel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1201377504.479b90e042ab7@webmail.in-berlin.de \
--to=oliver@first.in-berlin.de \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox