اختبار: إدارة الذاكرة الأساسية في 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.");

هذه القواعد تمنع سباقات البيانات أثناء التجميع، مما يجعل 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‑بت)
2. تُخزن البيانات الفعلية على الكومة
3. الآن يعرف المترجم بالضبط مقدار المساحة التي يجب تخصيصها

حالات الاستخدام الشائعة لـ Box<T>:

• هياكل بيانات متكررة (قوائم مرتبطة، أشجار)
• بيانات كبيرة تريد التأكد من تخصيصها على الكومة
• كائنات Traits عندما تحتاج إلى استدعاء ديناميكي

أفضل ممارسة: استخدم 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. استخدم المراجع عندما يكون عمر الهيكل أقصر بوضوح من عمر البيانات
3. فكر في عدة معاملات عمر عندما يمكن للمراجع أن تكون لها أعمار مختلفة
4. وثّق علاقات الأعمار في الهياكل المعقدة

يفشل هذا الكود لأن المترجم لا يستطيع تحديد العلاقة بين أعمار الإدخال والإخراج. إليك السبب وكيفية إصلاحه:

// Correct version with explicit lifetime annotation
fn longest<'a>(text1: &'a str, text2: &'a str) -> &'a str {
    if text1.len() > text2.len() {
        text1
    } else {
        text2
    }
}

// Alternative with different lifetimes
fn longest_flex<'a, 'b>(text1: &'a str, text2: &'b str) -> &'a str {
    if text1.len() > text2.len() {
        text1
    } else {
        text2.to_string().as_str() // Won't compile! Shows why we need same lifetime
    }
}

لماذا تحتاج الأعمار هنا:

1. مراجع الإدخال المتعددة قد تكون لها أعمار مختلفة
2. يجب أن تكون قيمة الإرجاع حية طوال عمر كلا الإدخالين
3. يحتاج المترجم إلى التحقق من هذه العلاقات

الأنماط الشائعة:

// Single input reference - elision works
fn first_word(s: &str) -> &str { /* ... */ }

// Multiple references, same lifetime needed
fn compare_str<'a>(s1: &'a str, s2: &'a str) -> &'a str { /* ... */ }

// Different lifetimes possible
fn combine<'a, 'b>(s1: &'a str, s2: &'b str) -> String { /* ... */ }

أفضل الممارسات:

1. دع استنتاج العمر يعمل عندما يكون ذلك ممكنًا
2. استخدم أعمارًا صريحة عندما تحتاج العلاقات إلى وضوح
3. فكر في إرجاع أنواع مملوكة لتجنب تعقيد العمر
4. وثّق العلاقات المعقدة للأعمار

RefCell يوفر القابلية للتغيير الداخلي لكنه لا يزال يفرض قواعد الاستعارة في Rust أثناء وقت التشغيل:

use std::cell::RefCell;

fn demonstrate_refcell() {
    let data = RefCell::new(42);

    // Correct way to use RefCell
    {
        let mut first = data.borrow_mut();
        *first += 1;
    } // first is dropped here

    // Now we can borrow again
    let second = data.borrow_mut();

    // Or multiple immutable borrows
    let read1 = data.borrow();
    let read2 = data.borrow(); // This is OK
}

المفاهيم الأساسية:

1. RefCell ينقل فحوصات الاستعارة إلى وقت التشغيل
2. يمكن أن يسبب panics إذا تم خرق القواعد
3. مفيد لنمط القابلية للتغيير الداخلي

حالات الاستخدام الشائعة:

• كائنات mock في الاختبارات
• تنفيذ هياكل ذات مراجع ذاتية
• عندما تحتاج إلى تعديل بيانات خلف مرجع مشترك

أفضل الممارسات:

1. فضل الاستعارة في وقت التجميع عندما يكون ذلك ممكنًا
2. حافظ على استعارات RefCell في نطاقات ضيقة
3. فكر في استخدام drop() لإنهاء الاستعارات صراحةً
4. استخدم RefCell فقط عندما تحتاج إلى القابلية للتغيير الداخلي

Cell و RefCell يخدمان أغراضًا مختلفة لتغيير داخلي:

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:

• يعمل بشكل أفضل مع الأنواع القابلة للنسخ
• لا يوجد API للاستعارة
• دائمًا ينسخ أو ينقل القيم

2. RefCell:

• يعمل مع أي نوع
• يحتوي على API للاستعارة
• فحص الاستعارة في وقت التشغيل

أفضل الممارسات:

1. استخدم Cell للأنواع القابلة للنسخ البسيطة (أرقام، منطقية، إلخ)
2. استخدم RefCell عندما تحتاج إلى استعارة المحتويات
3. حافظ على الحد الأدنى من التغييرات عبر Cell/RefCell
4. وثّق لماذا الحاجة إلى تغيير داخلي

تم تصميم 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 و RwLock أغراضًا مشابهة لكن في سياقات مختلفة:

// Single-threaded scenario with RefCell
use std::cell::RefCell;

struct SingleThreaded {
    data: RefCell<Vec<i32>>,
}

impl SingleThreaded {
    fn modify(&self) {
        self.data.borrow_mut().push(42);
    }
}

// Multi-threaded scenario with RwLock
use std::sync::RwLock;

struct ThreadSafe {
    data: RwLock<Vec<i32>>,
}

impl ThreadSafe {
    fn modify(&self) {
        self.data.write().unwrap().push(42);
    }
}

الاختلافات الرئيسية:

1. RefCell:

• يعمل في خيط واحد فقط
• لا يوجد عبء تزامن
• يثير panic عند انتهاك الاستعارة

2. RwLock:

• آمن للخيوط
• يضيف عبء تزامن
• يمكن أن يحجب الخيوط بدلاً من إحداث panic

أفضل الممارسات:

1. استخدم RefCell للمتغيرية الداخلية في بيئة خيط واحد
2. استخدم RwLock عندما تكون أمان الخيوط مطلوبًا
3. فكر في Mutex لتبسيط المتغيرية الآمنة للخيوط
4. وثّق متطلبات أمان الخيوط بوضوح

هذا الكود يوضح سيناريو deadlock كلاسيكي. إليك طريقة إصلاحه:

use std::sync::{Arc, Mutex};

// Correct way - Release lock before acquiring it again
fn safe_mutex() {
    let lock = Arc::new(Mutex::new(42));

    {
        let mut data = lock.lock().unwrap();
        *data += 1;
    } // Lock is released here

    // Now we can acquire it again
    let data2 = lock.lock().unwrap();
    println!("Value: {}", data2);
}

// Using multiple mutexes safely
fn multiple_mutexes() {
    let lock1 = Arc::new(Mutex::new(42));
    let lock2 = Arc::new(Mutex::new(43));

    // Always acquire locks in the same order
    let guard1 = lock1.lock().unwrap();
    let guard2 = lock2.lock().unwrap();
}

أفضل الممارسات لمنع الـ deadlock:

1. إبقاء الأقسام الحرجة صغيرة
2. تحرير الأقفال بسرعة باستخدام النطاقات
3. الحصول على أقفال متعددة بترتيب ثابت
4. استخدام parking_lot::Mutex لأداء أفضل
5. النظر في استخدام RwLock للأحمال الثقيلة للقراءة

الأنماط الشائعة:

// Thread-safe counter
struct Counter {
    count: Arc<Mutex<i32>>,
}

impl Counter {
    fn increment(&self) {
        let mut count = self.count.lock().unwrap();
        *count += 1;
    } // Lock automatically released here
}

المراجع الضعيفة لا تمنع تحرير أهدافها. إليك مثالًا مفصلاً:

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 في Rust إدارة الموارد بشكل صحيح. في هذا المثال، لا يحتاج 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. فكر في استخدام أنماط الحراسة للعمليات ذات النطاق المحدد

دعونا نفهم Copy vs Clone بالتفصيل:

// Types that can be Copy
#[derive(Copy, Clone)]
struct Point {
    x: i32,
    y: i32,
}

// Types that can only be Clone
#[derive(Clone)]
struct ComplexData {
    name: String,    // String can't be Copy
    points: Vec<i32> // Vec can't be Copy
}

// Manual implementation example
#[derive(Debug)]
struct Custom {
    data: Vec<i32>,
    identifier: u32,
}

impl Clone for Custom {
    fn clone(&self) -> Self {
        Custom {
            data: self.data.clone(),
            identifier: self.identifier,  // Copy type
        }
    }
}

الاختلافات الرئيسية:

1. Copy:

• نسخ ضمني على مستوى البت
• يجب أن يكون آمنًا للـ Copy (بدون تخصيصات على الـ heap)
• عادةً للأنواع الصغيرة التي تُخزن على الـ stack فقط

2. Clone:

• صريح، قد يكون نسخة عميقة
• يمكنه التعامل مع تخصيصات الـ heap
• أكثر مرونة لكنه قد يكون مكلفًا

أفضل الممارسات:

1. تنفيذ Copy للأنواع الصغيرة التي تُخزن على الـ stack فقط
2. استخدام Clone للأنواع التي تمتلك موارد
3. توثيق تأثيرات الأداء لـ Clone
4. النظر في تنفيذات Clone مخصصة للتحسين
5. توخي الحذر مع الاستنتاج التلقائي

لنُحلل تخطيط الذاكرة للهيكل وتحسينه:

// 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: محاذاة بايت واحد

2. استراتيجيات ترتيب الحقول:

• تجميع الحقول ذات الأحجام المتشابهة
• وضع المحاذاة الأكبر أولاً
• النظر في تحسين خط الذاكرة المؤقتة (cache line)

أفضل الممارسات:

1. للـ FFI أو افتراضات تخطيط ثابت، استخدم repr(...) المناسب
2. استخدم أحجام أعداد صحيحة مناسبة
3. فكر في استخدام Option للحقول الاختيارية
4. قس حجم الهياكل الحساسة للذاكرة باستخدام std::mem::size_of
5. استخدم #[repr(packed)] بحذر - قد يؤثر على الأداء

تتحول تجريدات Rust بلا تكلفة إلى شفرة فعّالة مكافئة عند التجميع:

use std::ops::Range;

// High-level abstraction
trait ZeroCost {
    fn process(&self) -> u32;
}

impl ZeroCost for Range<u32> {
    fn process(&self) -> u32 {
        self.fold(0, |acc, x| acc + x)
    }
}

// Compiles to essentially the same code as:
fn manual_process(range: Range<u32>) -> u32 {
    let mut sum = 0;
    let mut i = range.start;
    while i < range.end {
        sum += i;
        i += 1;
    }
    sum
}

// Even more abstractions, still zero-cost
fn complex_processing<T>(data: &[T]) -> u32
where T: AsRef<str> {
    data.iter()
        .map(|s| s.as_ref().len())
        .filter(|&n| n > 3)
        .fold(0, |acc, n| acc + n as u32)
}

المبادئ الأساسية:

1. ما لا تستخدمه لا تدفع ثمنه
2. ما تستخدمه لا يمكنك كتابة شفرة يدوية أفضل منه

أفضل الممارسات:

1. استخدم التجريدات عالية المستوى بحرية
2. ثق بتحسينات المترجم
3. قم بالتحليل قبل التحسين
4. ركّز على القابلية للقراءة أولاً
5. استخدم المكررات والإغلاق دون خوف