This is the mail archive of the
mailing list for the Guile project.
Re: New shared substring implementation
- To: forcer <firstname.lastname@example.org>
- Subject: Re: New shared substring implementation
- From: Mikael Djurfeldt <email@example.com>
- Date: 31 May 1999 18:12:13 +0200
- Cc: firstname.lastname@example.org
- Cc: email@example.com
- References: <199905310759.JAA17866@forcix.roof.lan>
forcer <firstname.lastname@example.org> writes:
> I liked the idea and wanted to implement it in guile.
I suppose you have noticed that Guile already has shared strings.
(see scm_make_shared_substring). What is missing is to use it
consistently throughout the code.
To get the simplest possible user interface, all code should produce
shared strings whenever possible, and coerce them into strings when
necessary. All traces of shared substrings in the interface should be
[I understand Christian Lynbech's point, but the vast majority of
users want to have a simple system. Those who want to use shared
substrings for communication can implement a specialized data
structure for this purpose.]
> Well, my thoughts about the copy-on-write idea stumbled on one
(BTW, have you noticed the macro SCM_COERCE_SUBSTR (which for some
strange reason is defined in symbols.h)? Generally, all operations
which mutate strings should call this macro.)
> (define str1 "foo") ; a string is allocated as usual
> (define str2 (substring str1 0 1)) ; str2 is now a shared
> ; substring of str1
> (string-set! str1 0 #\b) ; since str1 is not a shared
> ; substring, it's not copied,
> ; and thus str2 => "b"
> A solution to this problem would be to have (substring) mark the
> string it's applied to to be a "substring" as well. The problem
> then is that:
> (define str1 "foo")
> (define str2 (substring str1 2 3)) ; str1 and str2 are marked as
> ; shared substrings
> (string-set! str1 0 #\b) ; str1 now points to a newly
> ; malloc'd copy of the string,
> ; and str2 points to the
> ; original string
> (string-set! str2 0 #\b) ; str2 is now a copy of the
> ; string as well, and there's
> ; no pointer to the original
> ; string left :]
Hmm... Isn't this exactly what you want?
After the second string-set!, there's no reason to keep the original
string, so it should be freed.