Re: Segments

On 1/16/2025 11:12 AM, Terje Mathisen wrote:

Stephen Fuld wrote:

On 1/16/2025 1:11 AM, Terje Mathisen wrote:

Thomas Koenig wrote:

Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb:

Thomas Koenig <tkoenig@netcologne.de> writes:
[...]

CHERY targets C, which on the one hand, I understand (there's a
ton of C code out there), but trying to retrofit a safe memory
model onto C seems a bit awkward - it might have been better to
target a language which has arrays in the first place, unlike C.

[...]
>
C does have arrays.

>
Sort of - they decay into pointers at first sight.
>
But what I should have written was "multi-dimensional arrays",
with a reasonable way of handling them.
>

Rust provides an interesting data point here:
>
It has Vec<> which is always implemented as a dope vector, i.e. a header which contains the starting point and current length, along with allocated size. For multidimendional work, the natural mapping is Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with boundary checking.
>
However, in my own testing I have found that it is often faster to flatten those multi-dim vectors, and instead use explicit multiplication to get the actual position:
>
 Â  array[y][x] -> array[y*width + x]
>
Terje

>
I am obviously missing something, but why doesn't the compiler generate code for that itself?
>

 Because Rust really doesn't have multi-dim vectors, instead using vectors of pointers to vectors?
 OTOH, it is perfectly OK to create your own multi-dim data structure, and using macros you can probably get the compiler to generate near- optimal code as well, but afaik, nothing like that is part of the core language.

That surprised me.  So I did a search for "Rust Multi dimensional arrays", and got several hits.  It seems there are various ways to do this depending upon whether you want an array of arrays or a "traditional" multi-dimensional array. There is a crate for the latter.
I don't know enough Rust to get all the details in the various search results, but it seems there are options.
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)