ProgrammatieBackend ontwikkelaar

Beschrijf de verschillende soorten verwijzingen in Rust: de verschillen tussen mutabele en niet-mutable verwijzingen, regels voor exclusiviteit en levensduur, en hoe je correct functies schrijft die verschillende soorten verwijzingen accepteren. Geef voorbeelden van syntaxis en bespreek typische fouten bij het werken met verwijzingen.

Slaag voor sollicitatiegesprekken met de Hintsage AI-assistent

Antwoord

In Rust zijn er twee hoofdsoorten verwijzingen:

  • Niet-mutable verwijzingen (&T): bieden alleen toegang voor lezen.
  • Mutable verwijzingen (&mut T): maken het mogelijk om de waarde waarop wordt verwezen te wijzigen.

Regels:

  • Er kan gelijktijdig ofwel een onbeperkt aantal niet-mutable verwijzingen zijn, of slechts één mutable; ze kunnen niet in hetzelfde bereik worden gemengd.
  • Verwijzingen hebben een levensduur (lifetime), die op compileertijd wordt geanalyseerd.

Voorbeelden van syntaxis:

fn read(val: &i32) { println!("{}", val); } fn write(val: &mut i32) { *val += 1; } let mut x = 5; read(&x); write(&mut x);

Misleidende vraag

Vraag: Is het mogelijk om twee mutable verwijzingen naar één variabele in verschillende zichtbare gebieden van dezelfde functie te maken?

Antwoord: Nee, zelfs als de verwijzingen in verschillende blokken worden gemaakt, bestrijkt het bereik voor het analyseren van leningen de gehele functie of variabele, als de compiler niet kan bewijzen dat de verwijzingen elkaar niet overlappen. Dit leidt vaak tot compilerfouten:

let mut x = 10; let r1 = &mut x; { let r2 = &mut x; // fout! }

Voorbeelden van echte fouten door gebrek aan kennis van de nuances van het onderwerp


Verhaal

Bij de ontwikkeling van een parser probeerde de ontwikkelaar tegelijkertijd een mutabele en een niet-mutable verwijzing naar één buffer op te slaan voor het optimaliseren van lezen en schrijven. Als gevolg hiervan compileerde de code niet, en nadat ze het "ontweken" regel door unsafe verschenen er datalekken.


Verhaal

Aan het begin van een dataverwerkingsproject voerde een van de deelnemers geen "reanalyze borrow checker" uit voor complexe code met geneste gebieden. Als gevolg hiervan leidde dit, vanwege overlappende verwijzingen, tot de klassieke "cannot borrow as mutable because it's also borrowed as immutable"-fout zonder expliciete aanwijzing in de oorspronkelijke code voor het probleem.


Verhaal

In multi-threaded code gebruikten ze gewone verwijzingen om toegang te krijgen tot gedeelde gegevens. Bij het proberen om gegevens in parallelle threads te wijzigen, kregen ze onverwachte compilerfouten en dataraces bij het omzeilen van de borrow checker via onveilige code.