क्विज़: रस्ट मेमोरी मैनेजमेंट की मूल बातें

यह कोड 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 एक फिक्स्ड-साइज़ पॉइंटर प्रदान करता है (आमतौर पर 64-बिट सिस्टम पर 8 बाइट्स)
2. वास्तविक डेटा हीप (heap) पर स्टोर होता है
3. कंपाइलर को अब सटीक रूप से पता चल जाता है कि कितनी मेमोरी अलॉकेट करनी है

Box<T> के सामान्य उपयोग के मामले:

• रिकर्सिव डेटा स्ट्रक्चर्स (लिंक्ड लिस्ट, ट्रीज़)
• बड़ा डेटा जिसे आप हीप पर अलॉकेट करना चाहते हैं
• ट्रैइट ऑब्जेक्ट्स जब आपको डायनेमिक डिस्पैच की आवश्यकता हो

बेस्ट प्रैक्टिस: Box<T> का उपयोग तब करें जब आपको चाहिए:

• रिकर्सिव टाइप्स
• हीप अलोकेशन सुनिश्चित करना
• बिना कॉपी किए बड़े डेटा को मूव करना

आइए देखें कि Rc कैसे काम करता है:

1. Rc::new() के साथ प्रारंभिक निर्माण: count = 1
2. marcus के लिए पहला क्लोन: count = 2
3. aurelius के लिए दूसरा क्लोन: count = 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. जटिल स्ट्रक्चर्स में लाइफटाइम संबंधों को स्पष्ट रूप से डॉक्यूमेंट करें

लौटा हुआ रेफ़रेंस ऐसी लाइफ़टाइम के भीतर रहना चाहिए जो दोनों इनपुट के लिए मान्य हो। वह किसी भी उधार लिए गए मान से अधिक समय तक नहीं रह सकता। एनोटेशन संबंध बताते हैं, लाइफ़टाइम बढ़ाते नहीं।

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

प्रश्न में दूसरी borrow_mut() कॉल पर panic आता है क्योंकि पहला mutable borrow अभी मौजूद है। RefCell इस बॉरोइंग नियम की जाँच रनटाइम पर करता है। नीचे सही किए गए उदाहरण में drop(second) दो साझा borrows से पहले mutable borrow छोड़ता है।

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 टाइप्स के साथ सबसे अच्छा काम करता है
   • इसमें borrowing API नहीं होता
   • मान हमेशा कॉपी या मूव होते हैं

2. RefCell:

   • किसी भी टाइप के साथ काम करता है
   • इसमें borrowing API उपलब्ध है
   • रनटाइम पर borrow चेकिंग होती है

सर्वोत्तम अभ्यास:

1. सरल Copy टाइप्स (संख्याएँ, bool आदि) के लिए Cell का उपयोग करें
2. जब आपको सामग्री को borrow करने की आवश्यकता हो, तो RefCell का उपयोग करें
3. Cell/RefCell के माध्यम से होने वाले म्यूटेशन को न्यूनतम रखें
4. आंतरिक परिवर्तनशीलता की आवश्यकता क्यों है, इसे स्पष्ट रूप से दस्तावेज़ित करें

Rc (Reference Counting) को उन सिंगल-थ्रेडेड परिदृश्यों के लिए डिज़ाइन किया गया है जहाँ आपको शेयर्ड ओनरशिप की आवश्यकता होती है।

सामान्य उपयोग के मामले:

  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> रनटाइम में borrow की जाँच करता है और Sync नहीं है: उसका रेफ़रेंस थ्रेडों के बीच साझा न करें। T: Send होने पर उसे दूसरे थ्रेड में भेजा जा सकता है। RwLock<T> अपनी टाइप शर्तों के अनुसार सिंक्रनाइज़ किया गया एक्सेस देता है।

पहला guard छोड़े बिना एक ही थ्रेड में उसी mutex को दोबारा lock करने पर कॉल सामान्य रूप से नहीं लौटती। API डेडलॉक या panic दोनों की अनुमति देता है। दोबारा lock करने से पहले 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. ऑप्शनल रिलेशनशिप के लिए Weak रेफ़रेंस का उपयोग करें
2. इस्तेमाल करने से पहले upgrade() के रिज़ल्ट को चेक करें
3. ओनरशिप रिलेशनशिप को स्पष्ट रूप से डॉक्यूमेंट करें
4. सरल मामलों के लिए इंडेक्स जैसे विकल्पों पर विचार करें

Rust में 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. स्कोप्ड ऑपरेशंस के लिए गार्ड पैटर्न का उपयोग करने पर विचार करें

Copy अपने आप बिट-दर-बिट कॉपी करता है। Clone स्पष्ट रूप से बुलाया जाता है और मेमोरी आवंटित कर सकता है; यहाँ दोनों String फ़ील्ड की स्वतंत्र कॉपी बनती है। स्टैक या हीप पर होने से यह तय नहीं होता कि टाइप Copy लागू करता है।

आइए struct के मेमोरी लेआउट और ऑप्टिमाइज़ेशन को विस्तार से समझते हैं:

  // 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: सामान्य 64-बिट टारगेट पर 8-बाइट अलाइनमेंट और 24-बाइट साइज़
   • bool: 1-बाइट अलाइनमेंट

2. फ़ील्ड ऑर्डरिंग रणनीतियाँ:

   • समान साइज़ वाली फ़ील्ड्स को एक साथ रखें
   • बड़े अलाइनमेंट वाले को पहले रखें
   • कैश लाइन ऑप्टिमाइज़ेशन पर विचार करें

सर्वोत्तम प्रथाएँ:

1. FFI या स्थिर लेआउट मान्यताओं के लिए उपयुक्त repr(...) का उपयोग करें
2. उचित इंटीजर साइज़ चुनें
3. वैकल्पिक फ़ील्ड्स के लिए Option का उपयोग करने पर विचार करें
4. साइज़-क्रिटिकल structs को std::mem::size_of से मापें
5. #[repr(packed)] का उपयोग सावधानी से करें - यह प्रदर्शन को प्रभावित कर सकता है

Zero-cost abstraction कुशल ऑप्टिमाइज़्ड कोड संभव बनाते हैं; वे हर कंपाइलर या ऑप्टिमाइज़ेशन स्तर पर एक समान समय की गारंटी नहीं देते। दोनों फ़ंक्शन समान योग निकालते हैं। प्रदर्शन महत्वपूर्ण हो तो वास्तविक काम को मापें।

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)
    }
}