Liste des Groupes | Revenir à c arch |
David Brown wrote:On 17/09/2024 08:07, Terje Mathisen wrote:David Brown wrote:On 16/09/2024 10:37, Terje Mathisen wrote:>This becomes much simpler in Rust where usize is the only legal>
index type:
>
Yeah, you have to actually write it as
>
 Â y = p[x];
 Â x += 1;
>
instead of a single line, but this makes zero difference to the
compiler, right?
I don't care much about the compiler - but I don't think this is
an improvement for the programmer. (In general, I dislike
trying to do too much in a single expression or statement, but
some C constructs are common enough that I am happy with them.Â
It would be hard to formulate concrete rules here.)
>
And the resulting object code is less efficient than you get with
signed int and "y = p[x++];" (or "y = p[x]; x++;") in C.
Is that true? I'll have to check godbolt myself if that is really
the case!
It is not true - or at least, it shouldn't be true. I had thought
the Rust code was using the equivalent of a C "unsigned int" here,
which would require extra code for wrapping semantics. But that
was just my misunderstanding of Rust and its types - with a 64-bit
unsigned type, it should give the same results as C. However,
there's no harm in checking it and letting us know.
No need to check this particular point, Rust's usize was obviously
designed to be an unsigned type large enough to index into the entire
addressable memory range, so on a 64-bit platform it has to be 64
bits.That's actually surprising to me, I would have guessed any 32-bit
(I've previously shown how "y = p[x++];" in C is less efficient on
x86-64 if x is "unsigned int", compared to "int" or 64-bit types
for x.)
index would be less efficient than a full-width type, but if the
idionm is very, very common in C code, then it makes sense to make it
fast.
Doing so would typically require either sign- or zero-extending all
32-bit variables when loaded into a 64-bit register, right?
Terje
Les messages affichés proviennent d'usenet.