RISC-V OS using Rust: Graphics

Re:RISC-V OS using Rust: Graphics by a1369209993 on Monday August 03, 2020 @07:46PM (#24044865)

They're not talking about that - you could do:

  struct vec_int vec = VEC_INT_EMPTY;
  vec_int_push(&vec,1);
  vec_int_push(&vec,2);
  vec_int_push(&vec,3);

even in C. They're talking about things like:

  Foo foo; // Foo::Foo allocates
  z = x + y; // operator+ allocates
  w = x; // operator= allocates
  foo += *bar; // operator* allocates

Rust can do most of those things, but it's not encouraged and significantly less pervasive, especially in the kind of code you'd want to use in a kernel in the first place.

[ Parent | on HN ]

Re:RISC-V OS using Rust: Graphics by pjmlp on Tuesday August 04, 2020 @02:06AM (#24047136)

So it can, case closed. Being encouraged or not, doesn't control the hands of those typing the code.

[ Parent | on HN ]

Re:RISC-V OS using Rust: Graphics by unionpivo on Tuesday August 04, 2020 @08:57AM (#24049449)

> So it can, case closed. Being encouraged or not, doesn't control the hands of those typing the code.

Sure in theory. But in practice most consider such a behavior a code small or straight bug an d fix it.

So there is a difference in practice.

[ Parent | on HN ]

Re:RISC-V OS using Rust: Graphics by pjmlp on Tuesday August 04, 2020 @09:12AM (#24049585)

In theory every expert level C developer writes correct code, in practice errors happen.

[ Parent | on HN ]

Re:RISC-V OS using Rust: Graphics by estebank on Tuesday August 04, 2020 @10:52AM (#24050552)

The gp is slightly incorrect: in Rust you cannot override the constructor so that it allocates more than the struct itself. You can extend + and allocate in it, which is why it is treated in theory and practice as if it were a method call, because it is. You cannot override the assignment operator, it will always be either a conceptual move of ownership or a memcopy at worst, never a method call with any arbitrary number of heap allocations. Same for the dereferencing operator, it cannot be overriden. This is the reason we say there are no hidden allocations in Rust. In every language you might have allocations in a method call. Some languages consider assignment to be one for example, Rust doesn't.

[ Parent | on HN ]

Re:RISC-V OS using Rust: Graphics by jcelerier on Tuesday August 04, 2020 @02:35AM (#24047286)

This doesn't make a lot of sense to me. If a language has a feature, people will use it, encouraged or not. So I really don't see the argument there.

[ Parent | on HN ]

Re:RISC-V OS using Rust: Graphics by estebank on Tuesday August 04, 2020 @10:53AM (#24050569)

Of the examples given, Rust can only do the first one, overrides + because it is treated as just another method call. Assignments struct constructors and dereferencing always do what they look like they are doing as they cannot be overriden.

[ Parent | on HN ]

Re:RISC-V OS using Rust: Graphics by a1369209993 on Wednesday August 05, 2020 @06:47PM (#24066446)

> If a language has a feature, people will use it

You can also use asm blocks (or string literals casted to function pointers) to wreak all kinds of havok. Oddly, noone seems particularly concerned about that.

[ Parent | on HN ]