[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another alternative string representation proposal
From: |
Keisuke Nishida |
Subject: |
Re: Another alternative string representation proposal |
Date: |
22 Sep 2000 20:08:48 -0400 |
User-agent: |
T-gnus/6.14.4 (based on Gnus v5.8.6) (revision 02) SEMI/1.13.7 (Awazu) Chao/1.14.0 (Momoyama) Emacs/20.7 (i686-pc-linux-gnu) MULE/4.1 (AOI) |
Dirk Herrmann <address@hidden> writes:
> A char-field has the following attributes:
> * chars is a char* pointing to the first character of the character
> field.
> * length is an unsigned int denoting the number of characters in the
> character field.
> * owner_p is a boolean value that indicates whether the char-field is
> actually the owner of the character field, i. e. whether the character
> field should be freed if the char-field is garbage collected.
Is owner_p really necessary? If a char-field is read-only, it is not
the owner of the character sequence. If it is mutable or immutable,
we can force the char-field to own the sequence.
If a char-field is mutable and it does not own the sequence, it means
Guile is modifying memory space allocated by the user. I don't think
it's a very good idea. On the other hand, I don't see any reason why
a character sequence must be read-only when Guile manages it.
So, I think it is okay to always make C-strings given by the user to
be read-only, while making only those strings created in Guile mutable
or immutable.
> * mutability is a value from '(mutable, immutable, read-only) that
> determines whether modifications to the characters in the character
> field are allowed.
> * users is an unsigned integer value that denotes the number of scheme
> objects that share the char-field. This attribute is only used if
> mutability is 'immutable.
Why do you need the mutability field when you have the users count?
It seems to me that the following definition is sufficient:
users = -1 read-only
users = 0 no reference (can be GCed)
users = 1 mutable
users > 1 immutable
> * If mutability is 'immutable, and the number of users is larger than 1,
> then any operation that intends to modify the character field has to
> create a new mutable char-field object with its own copy of the
> character field. [...]
If the immutable char-field is very large, copying it costs much more
than copying its substring, while modifying the larger char-field more
likely happens. Probably creating a small substring from a large string
should be treated specially...