[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: food for thought re: string representations ["Boehm, Hans" <address@

From: Dirk Herrmann
Subject: Re: food for thought re: string representations ["Boehm, Hans" <address@hidden>] RE: Re: [gclist] ref-counting performance cost
Date: Thu, 12 Oct 2000 00:37:58 +0200 (MEST)

On 11 Oct 2000, Michael Livshin wrote:

> just caught this on the GC mailing list.  look for the comments on the 
> C++ string class near the end.

If I remember correctly, the problems with the C++ string class originate
from the following problem:

Take the expression
  s[pos] = c;
where s is a string.  How do you realize a copy-on-write semantics for
s?  This would only work if the assignment operation itself could be
overloaded, such that the assignment itself would perform a copying if

The code 's[pos] = c' is performed in the following way (transcribing into
a scheme-like syntax):
  (assign ([] s pos) c)
However, the result of ([] s pos) is just a reference to a single
character (an lvalue), which holds no reference to the string object where
the character originated from.

Thus, since the assignement operator does not have any access to the
string object any more, it can not determine whether the string is shared 
such that a copy-on-write should be performed.

For scheme, the problem does not exist in this way, since there is no
pointer to a character within a string.  All accesses to characters within
a string go through the string object itself.

Best regards

reply via email to

[Prev in Thread] Current Thread [Next in Thread]