[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The future: accessing vectors, arrays, etc from C
From: |
Marius Vollmer |
Subject: |
Re: The future: accessing vectors, arrays, etc from C |
Date: |
Tue, 11 Jan 2005 19:01:44 +0100 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) |
Neil Jerram <address@hidden> writes:
>> A change in representation of an array might happen when the copy for
>> a copy-on-write array takes place, or when the first 16-bit Unicode
>> character is stored in a 8-bit string.
>
> Just to check understanding: is it correct that:
>
> - all such changes have to be driven from Scheme code?
Hmm, I'm not sure what you are getting at. Certainly C code can
trigger these changes as well, but they do not happen spontaneously.
For example, you might get an error about not being allowed to change
a reserved array when you try to grow a vector while it is being
sorted in another thread. The thing to do then is to use some
synchronization (such as a mutex) to prevent this situation.
> - such changes do not affect the arrays obtained by C code through the
> scm_*_array_handle_*_elements functions?
Right. Those arrays are 'reserved' while C code accesses them and you
can't change them in a way that would invalidate the pointers that C
code is using.
>> It will be more tedious to use than the old one mainly because it is
>> more general, something which has nothing to do with allowing
>> representations to change: When using the new API, your code must be
>> able to deal with non-contiguously stored vectors, while previously
>> you could just assume that all vectors are stored contiguously.
>
> This worried me when I first read it, but in fact I think the only
> increase in tediousness is that the increment from one element to the
> next may not always be 1. But it will always be some constant. Is
> that right, or am I missing some other kinds of tediousness? :-)
That is exactly right.
(There are any number of schemes to store arrays in memory, just think
about sparse or band matrices, and we can't offer them all. I think
the current compromise by Guile is the right one.)
> I think this delta is OK, personally. And in practice many
> applications will be able to get away with asserting that the
> increment is 1, by simplying avoiding array mapping in more than one
> dimension.
Hmm, no, even vectors can have increments != 1. The diagonal of a
matrix would be an example.
> Even so, I think we could usefully make a public statement (perhaps by
> adding it to the manual) reflecting the apparent consensus from this
> discussion, namely...
Yours is a very good summary, but I myself wouldn't want to put it in
the manual... just let reality speak for itself. But it should be
recorded somewhere. Maybe in the FAQ?
>> [...]
>
> Sounds good and sufficiently motivated to me. I presume SCM_VECTORP,
> SCM_VECTOR_REF and SCM_VECTOR_SET will remain available as deprecated
> macros, won't they?
Yes, but their performance sucks.
- Re: The future: accessing vectors, arrays, etc from C, Kevin Ryde, 2005/01/03
- Re: The future: accessing vectors, arrays, etc from C, Neil Jerram, 2005/01/04
- Re: The future: accessing vectors, arrays, etc from C, Mike Gran, 2005/01/04
- Re: The future: accessing vectors, arrays, etc from C, Thien-Thi Nguyen, 2005/01/05
- Re: The future: accessing vectors, arrays, etc from C, Marius Vollmer, 2005/01/05
- Re: The future: accessing vectors, arrays, etc from C, Neil Jerram, 2005/01/08
- Re: The future: accessing vectors, arrays, etc from C,
Marius Vollmer <=
- Re: The future: accessing vectors, arrays, etc from C, Mikael Djurfeldt, 2005/01/11
- Re: The future: accessing vectors, arrays, etc from C, Neil Jerram, 2005/01/15
- Re: The future: accessing vectors, arrays, etc from C, Neil Jerram, 2005/01/16