חידון: ניהול זיכרון חיוני ב‑Rust

קוד זה נכשל בקומפילציה בגלל חוקי הבעלות של Rust. כאשר אנו משייכים את philosopher ל-greeting, הבעלות על ה-String מועברת ל-greeting. אחרי העברה זו, philosopher אינו תקף יותר לשימוש.

הנה שלוש דרכים לתקן זאת:

1. לשכפל את המחרוזת (יוצר עותק חדש):

let greeting = philosopher.clone();

2. להשתמש בהתייחסות (שואלת את הערך):

let greeting = &philosopher;

3. להשתמש בחיתוך מחרוזת (שואלת חלק מהמחרוזת):

let greeting = &philosopher[..];

לכל פתרון יש מקרי שימוש והשפעות ביצועים שונים. שכפול יקר יותר אך נותן בעלות, בעוד שהפניות זולות יותר אך יש להן מגבלות זמן חיים.

הקוד נכשל בקומפילציה מכיוון שהבעלות של wisdom הועברה ל‑take_knowledge ולכן לא ניתן להשתמש בו לאחר מכן.

הנה שלוש דרכים לתקן את הבעיה:

1. להעביר לפי הפניה (להשאיל את הערך):

fn borrow_it(text: &String) {
    println!("Inside: {}", text);
}
borrow_it(&wisdom);  // Now wisdom can be used after

2. לשכפל את הערך (ליצור עותק חדש):

take_knowledge(wisdom.clone());  // Original wisdom remains valid

3. להחזיר את הבעלות מהפונקציה:

fn take_and_return(text: String) -> String {
    println!("Inside: {}", text);
    text  // Return ownership back
}
let wisdom = take_and_return(wisdom);  // Reassign returned ownership

כל גישה יש לה שימושים שונים:

• הפניות: היעילה ביותר, אך דורשת ניהול זמן חיים
• שכפול: פשוט אך עלול להיות יקר
• החזרת בעלות: שימושי לשינוי ערכים

הפרקטיקה הטובה ביותר: השתמשו בהפניות אלא אם כן אתם צריכים העברת בעלות.

הקוד הזה מפר את כללי ההשאלה הבסיסיים של Rust:

• רק הפנייה ניתנת לשינוי אחת לערך בכל זמן
• או כל מספר של הפניות בלתי ניתנות לשינוי
• הפניות אינן יכולות לחיות יותר מהמקור שלהן

הנה איך לתקן את הקוד:

1. השתמשו בתחומי זמן רצופים:

let mut wisdom = String::from("He who laughs at");
{
    let ref1 = &mut wisdom;
    ref1.push_str(" himself never runs");
}  // ref1 goes out of scope
let ref2 = &mut wisdom;  // Now this is valid
ref2.push_str(" out of things to laugh at.");

2. או שנו את המחרוזת בהשאלה אחת:

let mut wisdom = String::from("He who laughs at");
let ref1 = &mut wisdom;
ref1.push_str(" himself never runs out of things to laugh at.");

הכללים האלה מונעים מרוצי נתונים (data races) בזמן הקומפילציה, מה שהופך את Rust לבטוח מבחינת תהליכונים כברירת מחדל.

טעות נפוצה: ניסיון להשתמש בכמה הפניות ניתנות לשינוי כדי להימנע משכפול או כדי לשנות חלקים שונים של אותו ערך במקביל.

הקוד הזה מתקמפל בהצלחה הודות לכללי השמטת ציוני זמן חיים של Rust. כללים אלו מאפשרים למקמפל להסיק באופן אוטומטי זמני חיים בתבניות נפוצות.

שלושת כללי השמטת ציוני זמן חיים הם:

1. לכל פרמטר יש פרמטר זמן חיים משלו
2. אם יש בדיוק פרמטר זמן חיים קלט אחד, זמן החיים הזה מוקצה לכל פרמטרי זמן החיים של הפלט
3. אם יש כמה פרמטרי זמן חיים קלט, אך אחד מהם הוא &self או &mut self, זמן החיים של self מוקצה לכל פרמטרי זמן החיים של הפלט

הפונקציה הזו שווה ל:

fn first_word<'a>(s: &'a str) -> &'a str {
    // ... same implementation
}

תבניות נפוצות שבהן השמטת ציוני זמן חיים פועלת:

// These don't need explicit lifetimes
fn get_str(s: &str) -> &str { s }
fn get_first(s: &str) -> &str { &s[0..1] }

// These would need explicit lifetimes
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

המלצה: תן להשמטת ציוני זמן חיים לעבוד בשבילך כשאפשר, אך הבן מתי נדרשים זמני חיים מפורשים.

קוד זה נכשל מכיוון שהקומפיילר לא יכול לקבוע את הגודל של CatList בזמן הקומפילציה. הטבע הרקורסיבי של הסוג אומר שהוא יכול להיות אינסופית גדול!

הנה איך לתקן זאת בעזרת Box<T>:

#[derive(Debug)]
enum CatList {
    Cons(i32, Box<CatList>),  // Box provides a fixed-size pointer
    Nil,
}

fn main() {
    let catlist = CatList::Cons(1,
        Box::new(CatList::Cons(2,
            Box::new(CatList::Cons(3,
                Box::new(CatList::Nil))))));
}

למה Box<T> עובד:

1. Box מספק מצביע בגודל קבוע (בדרך כלל 8 בתים במערכות 64‑bit)
2. הנתונים האמיתיים מאוחסנים על ההיפ
3. הקומפיילר עכשיו יודע בדיוק כמה מקום להקצות

מקרים נפוצים לשימוש ב-Box<T>:

• מבנים רקורסיביים (רשימות מקושרות, עצים)
• נתונים גדולים שאתה רוצה להבטיח שהם יוקצו על ההיפ
• אובייקטים של traits כשצריך דינמיקה של dispatch

פרקטיקה מומלצת: השתמש ב-Box<T> כאשר אתה צריך:

• סוגים רקורסיביים
• להבטיח הקצאת היפ
• להעביר נתונים גדולים בלי להעתיק

בואו נפרק איך Rc עובד:

1. יצירה ראשונית עם Rc::new(): ספירה = 1
2. שכפול ראשון עבור marcus: ספירה = 2
3. שכפול שני עבור aurelius: ספירה = 3

מאפייני Rc חשובים:

use std::rc::Rc;

fn demonstrate_rc() {
    let original = Rc::new(String::from("Shared"));
    println!("Count after creation: {}", Rc::strong_count(&original)); // 1

    {
        let copy = Rc::clone(&original);
        println!("Count inside scope: {}", Rc::strong_count(&original)); // 2
    } // copy is dropped here

    println!("Count after scope: {}", Rc::strong_count(&original)); // 1
}

נקודות מפתח:

• Rc::clone() זול - הוא רק מגדיל מונה
• Rc מיועד רק לתרחישים בעלי תהליכון יחיד
• כאשר ההפניה האחרונה נזרקת, הנתונים מנוקים
• השתמשו בהתייחסויות Weak כדי למנוע מחזורי הפניות

שיטות מומלצות:

• השתמשו ב‑Rc כשאתם צריכים בעלות משותפת
• שקלו Arc לתרחישים בטוחים בריבוי תהליכונים
• הימנעו מיצירת מחזורי הפניות

הקוד נכשל מכיוון שמבנים שמכילים הפניות חייבים לציין זמני חיים. הנה איך לתקן זאת:

// Single lifetime parameter
struct Philosopher<'a> {
    name: &'a str,
    quote: &'a str,
}

// Or different lifetimes if needed
struct PhilosopherFlex<'n, 'q> {
    name: &'n str,
    quote: &'q str,
}

תבניות נפוצות:

// Own the data instead
struct PhilosopherOwned {
    name: String,
    quote: String,
}

// Mixed ownership
struct PhilosopherMixed<'a> {
    name: String,      // Owned
    quote: &'a str,    // Borrowed
}

שיטות מומלצות:

1. השתמשו בסוגים בבעלות (String) כשצריך לאחסן נתונים ללא גבול זמן
2. השתמשו בהפניות כשזמן החיים של ה-struct ברור שהוא קצר יותר מהנתונים
3. שקלו מספר פרמטרי זמן חיים כאשר ההפניות יכולות להיות עם זמני חיים שונים
4. תעדו את יחסי זמני החיים במבנים מורכבים

ההפניה המוחזרת חייבת להישאר בתוך זמן חיים התקף לשני ערכי הקלט. היא אינה יכולה לחיות מעבר לאף אחד מהם. ציוני זמן חיים מתארים את הקשר ואינם מאריכים את חיי הערכים.

fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() > b.len() { a } else { b }
}

קוד השאלה גורם לפאניקה בקריאת borrow_mut() השנייה, משום שההשאלה הניתנת לשינוי הראשונה עדיין חיה. RefCell אוכף כלל השאלה זה בזמן ריצה. בדוגמה המתוקנת למטה, drop(second) משחררת את ההשאלה הניתנת לשינוי לפני יצירת שתי ההשאלות המשותפות.

use std::cell::RefCell;
fn main() {
    let data = RefCell::new(42);
    let mut second = data.borrow_mut();
    *second += 1;
    drop(second);
    let read1 = data.borrow();
    let read2 = data.borrow();
    println!("{} {}", *read1, *read2);
}

Cell ו‑RefCell משמשים למטרות שונות של שינוי פנימי (interior mutability):

use std::cell::{Cell, RefCell};

// Cell for Copy types
struct Counter {
    count: Cell<i32>,
}

impl Counter {
    fn increment(&self) {
        self.count.set(self.count.get() + 1);
    }
}

// RefCell for non-Copy types
struct Logger {
    messages: RefCell<Vec<String>>,
}

impl Logger {
    fn log(&self, msg: &str) {
        self.messages.borrow_mut().push(msg.to_string());
    }
}

הבדלים מרכזיים:

1. Cell:

• עובד הכי טוב עם טיפוסים Copy
• אין API להשאלת ערכים
• תמיד מעתיק או מזיז ערכים

2. RefCell:

• עובד עם כל טיפוס
• כולל API להשאלת ערכים
• בדיקת השאלות בזמן ריצה

שיטות עבודה מומלצות:

1. השתמש ב‑Cell עבור טיפוסים Copy פשוטים (מספרים, bool וכו’).
2. השתמש ב‑RefCell כשצריך להשאיל את התוכן.
3. שמור על מינימום שינויים דרך Cell/RefCell.
4. תעד מדוע נדרש שינוי פנימי (interior mutability).

Rc (ספירת הפניות) מיועד לתרחישים בעלי תהליכון יחיד שבהם נדרשת בעלות משותפת.

מקרי שימוש נפוצים:

use std::rc::Rc;
use std::cell::RefCell;

// Shared ownership in data structures
struct Node {
    next: Option<Rc<Node>>,
    value: i32,
}

// Combining with interior mutability
struct SharedState {
    data: Rc<RefCell<Vec<String>>>,
}

// Multiple owners of same data
let original = Rc::new(vec![1, 2, 3]);
let clone1 = Rc::clone(&original);
let clone2 = Rc::clone(&original);

נקודות מפתח:

1. השתמשו ב‑Rc כאשר:

• חלקים מרובים בקוד שלכם צריכים בעלות
• אתם יודעים שהשיתוף הוא חד-חוטי
• זמני החיים אינם ניתנים לקביעות סטטית

2. השתמשו ב‑Arc במקום כאשר:

• אתם זקוקים לשיתוף בטוח בתהליכונים
• תהליכונים מרובים צריכים בעלות

3. מגבלות של Rc:

• אינו בטוח בתהליכונים
• עומס ריצה קל
• לא יכול לשבור מחזורי הפניות באופן אוטומטי

שיטות עבודה מומלצות:

1. העדיפו בעלות ייחודית כשאפשר
2. השתמשו ב‑Rc לבעלות משותפת בתהליכון יחיד
3. השתמשו ב‑Arc לתרחישים מרובי תהליכונים
4. שלבו עם Weak כדי למנוע מחזורי הפניות

RefCell<T> בודק השאלות בזמן ריצה ואינו Sync: אין לשתף הפניה אליו בין תהליכונים. אפשר להעביר אותו לתהליכון אחר כאשר T: Send. RwLock<T> מספק גישה מסונכרנת בכפוף למגבלות הטיפוס.

נעילת אותו mutex פעמיים באותו תהליכון בלי לשחרר את הנעילה הראשונה אינה חוזרת כרגיל. ה־API מאפשר קיפאון או פאניקה. יש לשחרר את ה־guard לפני נעילה נוספת.

use std::sync::Mutex;
fn main() {
    let lock = Mutex::new(42);
    { let mut guard = lock.lock().unwrap(); *guard += 1; }
    let guard = lock.lock().unwrap();
    println!("{}", *guard);
}

הפניות חלשות אינן מונעות שחרור של היעדים שלהן. הנה דוגמה מפורטת:

use std::rc::{Rc, Weak};
use std::cell::RefCell;

// Parent-child tree structure avoiding reference cycles
struct Node {
    next: Option<Rc<Node>>,
    parent: RefCell<Weak<Node>>,  // Weak to prevent cycles
    value: i32,
}

impl Node {
    fn new(value: i32) -> Rc<Node> {
        Rc::new(Node {
            next: None,
            parent: RefCell::new(Weak::new()),
            value,
        })
    }

    fn set_parent(&self, parent: &Rc<Node>) {
        *self.parent.borrow_mut() = Rc::downgrade(parent);
    }

    fn get_parent(&self) -> Option<Rc<Node>> {
        self.parent.borrow().upgrade()
    }
}

מקרים נפוצים:

1. מבנים דמויי מטמון שבהם ניתן למחוק רשומות
2. מבני עץ עם הפניות להורים
3. תבניות מתצפית שבהן נושאים יכולים להיות מוסרים
4. שבירת מחזורי הפניות במבני נתונים מורכבים

שיטות מומלצות:

1. השתמשו בהפניות חלשות עבור יחסים אופציונליים
2. בדקו תוצאות של upgrade() לפני השימוש
3. תעדו יחסי בעלות בצורה ברורה
4. שקלו חלופות כמו אינדקסים למקרים פשוטים יותר

RAII ברוסט מבטיח שהמשאבים מנוהלים כראוי. בדוגמה זו, FileWrapper אינו זקוק למימוש מותאם של Drop כדי לסגור את ידית הקובץ: שדה ה-File שלו משוחרר אוטומטית כאשר המעטפת יוצאת מהתחום.

מיישמים Drop רק כאשר למעטפת עצמה יש התנהגות ניקוי נוספת מעבר לשחרור השדות שלה:

use std::fs::File;
use std::io::{self, Write};

struct FileWrapper {
    file: File,
    path: String,
}

impl FileWrapper {
    fn new(path: &str) -> io::Result<FileWrapper> {
        Ok(FileWrapper {
            file: File::create(path)?,
            path: path.to_string(),
        })
    }

    fn write(&mut self, content: &str) -> io::Result<()> {
        self.file.write_all(content.as_bytes())
    }
}

impl Drop for FileWrapper {
    fn drop(&mut self) {
        // Ensure file is properly closed
        // Could also do cleanup like deletion
        println!("Closing file: {}", self.path);
    }
}

תבניות RAII:

1. הבונה רוכש משאבים
2. השיטות משתמשות במשאבים בבטחה
3. השדות משוחררים אוטומטית כאשר הבעלים יוצא מהתחום
4. Drop מותאם מוסיף ניקוי נוסף כשצריך
5. השתמש ב-? להפצת שגיאות

שיטות עבודה מומלצות:

1. הסתמך על מימושי Drop של ספריית הסטנדרט כאשר הם כבר מודלים את המשאב
2. שמור על ניהול משאבים פשוט וברור
3. השתמש בסוגי ספריית הסטנדרט כשאפשר
4. תעד את התנהגות הניקוי
5. שקול להשתמש בתבניות guard לפעולות בתחומי זמן

Copy מבצע העתקה משתמעת, ביט־לביט. Clone הוא מפורש ועשוי להקצות זיכרון; כאן שני שדות ה־String מקבלים עותקים עצמאיים. מיקום הערך במחסנית או בערימה אינו קובע אם הטיפוס מממש Copy.

בואו נפרק את פריסת הזיכרון של המבנה והאופטימיזציה:

// Typical current 64-bit Rust layout: 32 bytes
struct Metadata {
    id: u32,       // 4 bytes
    name: String,  // 24 bytes on 64-bit systems
    active: bool   // 1 byte + padding/alignment
}

// Reordering fields may reduce padding for repr(C) structs,
// but default Rust layout is not a stable ABI guarantee.
struct OptimizedMetadata {
    name: String,   // 24 bytes
    id: u32,       // 4 bytes
    active: bool    // 1 byte + 3 padding
}

// Further optimization with packing
#[repr(packed)]
struct PackedMetadata {
    id: u32,
    active: bool,
    name: String,
}

שיקולים של פריסת הזיכרון:

1. דרישות יישור:

• u32: יישור של 4 בתים
• String: יישור של 8 בתים ו‑גודל של 24 בתים במערכות 64‑ביט נפוצות
• bool: יישור של 1 בתים

2. אסטרטגיות סדר השדות:

• קבץ שדות בעלי גודל דומה
• הצב יישורים גדולים יותר ראשונים
• שקול אופטימיזציית קו מטמון

שיטות עבודה מומלצות:

1. עבור FFI או הנחות פריסה יציבה, השתמש ב‑repr(...) מתאים
2. השתמש בגודלי שלמים מתאימים
3. שקול להשתמש ב‑Option לשדות אופציונליים
4. מדוד מבנים קריטיים לגודל עם std::mem::size_of
5. השתמש ב‑#[repr(packed)] בזהירות – זה יכול להשפיע על הביצועים

הפשטות ללא עלות מאפשרות קוד יעיל לאחר אופטימיזציה, אך אינן מבטיחות זמני ריצה זהים בכל קומפיילר או רמת אופטימיזציה. שתי הפונקציות מחשבות אותו סכום. כשביצועים חשובים, יש למדוד את העומס בפועל.

use std::ops::Range;
trait ZeroCost {
    fn process(&self) -> u32;
}
impl ZeroCost for Range<u32> {
    fn process(&self) -> u32 {
        self.clone().fold(0, |acc, x| acc + x)
    }
}