mboost-dp1
Rust
Sproget har i hvertfald nogle nuancer. Men kompileren er ret så genial. Det er på niveau med C# (hvis ikke bedre) til at foreslå hvad du har gjort forkert i din kode, advare mod unwanted copies/clones, unsafe, etc.
Jeg har et repo hvor jeg laver samme program i forskellige sprog, og Rust var faktisk ret nemt (en del nemmere end C!), https://github.com/clausjoergensen/game_of_life/bl...
Jeg har et repo hvor jeg laver samme program i forskellige sprog, og Rust var faktisk ret nemt (en del nemmere end C!), https://github.com/clausjoergensen/game_of_life/bl...
Et eksempel på hvor kompileren imponerede mig.
I C (og alle andre sprog) skrev jeg følgende:
I Rust bliver man advaret mod at x - 1 vil "wrap around". Hvis man f.eks. brugte unsigned integers kunne det jo lede til en side-effekt i C (jeg mener ikke C++ har overflow på uints?)
Modsat hvis man skriver:
Specifikt ser man følgende:
Og så en runtime fejl:
I C (og alle andre sprog) skrev jeg følgende:
if ((x - 1) >= 0) {I Rust bliver man advaret mod at x - 1 vil "wrap around". Hvis man f.eks. brugte unsigned integers kunne det jo lede til en side-effekt i C (jeg mener ikke C++ har overflow på uints?)
Modsat hvis man skriver:
if x >= 1opnår man samme løsning uden et potential overflow.
Specifikt ser man følgende:
warning: comparison is useless due to type limits
--> game_of_life.rs:11:8
|
11 | if (x - 1) >= 0 {
| ^^^^^^^^^^^^
Og så en runtime fejl:
thread 'main' panicked at 'attempt to subtract with overflow', game_of_life.rs:11:8
#3
[dine eksempler ikke ikke helt ens da du har valgt unsigned i Rust og signed i C/C++]
Der er vel reelt to problem stillinger her:
A) test som altid er sandt (en unsigned variabel >= 0)
C og C++ : vi formoder at programmøren ved hvad han laver og returnerer true
Rust : vi informerer lige udvikleren om at der er noget mistænkeligt her
B) unsigned suktraktion der giver negativt resultat
C og C++ : per standard så laver vi udregninger på unsigned i modulus, så med 32 bit unsigned så giver 0U-1 altså 4294967295, og det er ikke vores skyld hvis programmøren ikke har læst C standarden og ved det
Rust : Houston we have a problem
[dine eksempler ikke ikke helt ens da du har valgt unsigned i Rust og signed i C/C++]
Der er vel reelt to problem stillinger her:
A) test som altid er sandt (en unsigned variabel >= 0)
C og C++ : vi formoder at programmøren ved hvad han laver og returnerer true
Rust : vi informerer lige udvikleren om at der er noget mistænkeligt her
B) unsigned suktraktion der giver negativt resultat
C og C++ : per standard så laver vi udregninger på unsigned i modulus, så med 32 bit unsigned så giver 0U-1 altså 4294967295, og det er ikke vores skyld hvis programmøren ikke har læst C standarden og ved det
Rust : Houston we have a problem
arne_v (4) skrev:Rust : Houston we have a problem
Hvad med scenariet hvor man beregner differencen mellem to timer counts, der kan løbe over. F.eks. med en 8 bit counter: A = 50, B = 60, differencen er B - A = 10, nemt. Næste eksempel: A = 250, B = 4. Nu giver B - A reelt et negativt resultat, men det forventede 10 kommer alligevel ud i C (hvis ellers A og B er uint8_t).
Mon rust vil brokke sig over sådan et nummer?
#6
Det her panikker:
Det her virker:
Og det er vel fair nok. Den første kode kunne være en fejl. I den anden kode er det ret klart at man ønsker wrap.
Det her panikker:
fn main() {
let a:u8 = 250;
let b:u8 = 4;
let c = b - a;
println!("{}", c);
}
Det her virker:
use std::num::Wrapping;
fn main() {
let a:u8 = 250;
let b:u8 = 4;
let c = Wrapping(b) - Wrapping(a);
println!("{}", c);
}
Og det er vel fair nok. Den første kode kunne være en fejl. I den anden kode er det ret klart at man ønsker wrap.
#7 Blæret! Jo mere "skåret ud i pap" kode er, jo bedre.
... tager for givet at assembler output i sidste eksempel kun er en subtract og ikke har overhead pga. Wrapping(..) ?
... hvis den panikker i første eksempel, så er der jo et runtime overflow check. Reelt bør koden med wrapping ende med færre instruktioner ?
... tager for givet at assembler output i sidste eksempel kun er en subtract og ikke har overhead pga. Wrapping(..) ?
... hvis den panikker i første eksempel, så er der jo et runtime overflow check. Reelt bør koden med wrapping ende med færre instruktioner ?
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund