Rust में Ownership और Borrowing – Ownership and Borrowing in Rust

Rust की सबसे खास विशेषताओं में से एक इसका मेमोरी प्रबंधन है, जिसे Ownership और Borrowing की अवधारणाओं के माध्यम से लागू किया गया है। Rust का Ownership सिस्टम यह सुनिश्चित करता है कि मेमोरी लीकेज या डेंग्लिंग पॉइंटर जैसी समस्याएँ न हों, और प्रोग्राम अधिक सुरक्षित और कुशल बने। इस अध्याय में, हम विस्तार से समझेंगे कि Rust में Ownership और Borrowing कैसे काम करते हैं, और साथ ही Lifetimes की अवधारणा को भी जानेंगे, जो मेमोरी सुरक्षा के लिए महत्वपूर्ण है।

Ownership का सिद्धांत (The Principle of Ownership)

Rust की सबसे खास विशेषता उसका Ownership सिस्टम है, जो मेमोरी सुरक्षा को सुनिश्चित करता है और डेवलपर्स को बिना मैन्युअल मेमोरी प्रबंधन (manual memory management) के सुरक्षित कोड लिखने में मदद करता है। Rust में मेमोरी और डेटा का प्रबंधन एक अनूठे तरीके से किया जाता है, जिसमें हर वैल्यू का एक मालिक (owner) होता है, और जब वह मालिक अपनी वैल्यू के साथ समाप्त हो जाता है, तो वह मेमोरी स्वचालित रूप से साफ़ हो जाती है। इसे ownership कहा जाता है।

Ownership का सिद्धांत Rust के तीन मुख्य नियमों पर आधारित है:

Ownership के तीन नियम (Three Rules of Ownership)

1. हर वैल्यू का एक मालिक होता है (Each Value Has a Single Owner):
   • जब भी आप किसी वैल्यू को Rust में असाइन करते हैं, तो उस वैल्यू का केवल एक ही मालिक होता है। मालिक वह वैरिएबल होता है जिसे वैल्यू असाइन की जाती है।
2. एक समय में एक ही मालिक होता है (Only One Owner at a Time):
   • एक वैल्यू का एक ही मालिक होता है, और जैसे ही वह वैल्यू किसी दूसरे वैरिएबल को सौंप दी जाती है, पहला वैरिएबल उसका मालिक नहीं रहता। इसे move कहा जाता है। इससे यह सुनिश्चित होता है कि किसी वैल्यू को एक ही समय में कई हिस्सों से नहीं बदला जा सकता।
3. जब मालिक स्कोप के बाहर जाता है, तो वैल्यू को हटा दिया जाता है (When the Owner Goes Out of Scope, the Value is Dropped):
   • जैसे ही वैरिएबल का स्कोप समाप्त हो जाता है, वैल्यू स्वचालित रूप से मेमोरी से हटा दी जाती है। इसे drop कहा जाता है। इससे मेमोरी लीकेज जैसी समस्याएँ नहीं होती हैं।

Ownership का उदाहरण (Example of Ownership)

आइए इसे एक उदाहरण से समझते हैं:

fn main() {
    let s1 = String::from("नमस्ते");  // s1 वैरिएबल "नमस्ते" का मालिक है
    let s2 = s1;  // s1 से s2 में वैल्यू मूव हो गई

    // println!("{}", s1);  // यह कोड एरर देगा क्योंकि s1 अब वैल्यू का मालिक नहीं है
    println!("{}", s2);  // s2 अब वैल्यू का नया मालिक है
}

इस उदाहरण में, पहले s1 वैरिएबल “नमस्ते” स्ट्रिंग का मालिक था। लेकिन जैसे ही हमने s1 को s2 में असाइन किया, वैल्यू को s1 से move कर दिया गया और अब s2 वैल्यू का मालिक है। इसलिए s1 का उपयोग करने पर Rust एरर देता है, क्योंकि वह अब वैल्यू का मालिक नहीं रहा।

Move और Clone (Move vs Clone)

Rust में जब किसी वैल्यू को एक वैरिएबल से दूसरे में असाइन किया जाता है, तो वैल्यू को move किया जाता है, जैसा कि ऊपर के उदाहरण में देखा गया। लेकिन यदि आप वैल्यू की एक कॉपी बनाना चाहते हैं, तो आपको clone का उपयोग करना होगा।

Clone का उदाहरण:

fn main() {
    let s1 = String::from("नमस्ते");
    let s2 = s1.clone();  // वैल्यू को क्लोन करके s2 में कॉपी किया गया

    println!("s1: {}, s2: {}", s1, s2);
}

इस उदाहरण में, clone के उपयोग से s1 की एक कॉपी s2 में बनाई गई है। अब दोनों वैरिएबल्स अपने-अपने डेटा के मालिक हैं और दोनों का उपयोग किया जा सकता है।

Ownership और स्टैक (Stack) एवं हीप (Heap)

Rust में छोटे और निश्चित आकार के डेटा (जैसे integers) को stack पर स्टोर किया जाता है, जबकि बड़े या डायनामिक आकार के डेटा (जैसे strings) को heap पर स्टोर किया जाता है। Ownership सिस्टम इस मेमोरी प्रबंधन को भी संभालता है, जिससे Rust में कोई मैन्युअल मेमोरी अलोकेशन की आवश्यकता नहीं होती। जैसे ही किसी वैरिएबल का स्कोप समाप्त होता है, उसकी मेमोरी को स्वचालित रूप से drop कर दिया जाता है।

Ownership के फायदे (Benefits of Ownership)

1. मेमोरी सुरक्षा (Memory Safety):
   • Ownership सिस्टम यह सुनिश्चित करता है कि मेमोरी लीक या डेंग्लिंग पॉइंटर्स जैसी समस्याएँ न हों। जब कोई वैल्यू स्कोप से बाहर होती है, तो Rust स्वचालित रूप से उसकी मेमोरी को फ्री कर देता है।
2. बिना गारबेज कलेक्शन के मेमोरी प्रबंधन (Memory Management Without Garbage Collection):
   • Rust में कोई गारबेज कलेक्टर नहीं होता। Ownership सिस्टम इस प्रकार डिज़ाइन किया गया है कि मेमोरी को साफ़ करने का काम compile-time पर ही हो जाता है।
3. कोड की सुरक्षा और प्रदर्शन (Safety and Performance):
   • Ownership सिस्टम के कारण Rust कोड अधिक सुरक्षित और तेज़ होता है, क्योंकि यह compile-time पर ही मेमोरी से संबंधित समस्याओं को पकड़ लेता है।

Borrowing और References (Borrowing and References)

Rust का Ownership सिस्टम काफी सख्त है, लेकिन यह हमें Borrowing और References के माध्यम से वैल्यू का उपयोग करने का एक लचीला तरीका भी प्रदान करता है। Ownership के नियमों के तहत, किसी वैल्यू का एक समय में केवल एक मालिक हो सकता है। लेकिन कई बार हमें वैल्यू को बिना Ownership स्थानांतरित किए दूसरे हिस्सों से एक्सेस करने की जरूरत होती है। यही जगह है जहाँ borrowing और references का उपयोग होता है।

Borrowing का अर्थ है कि आप एक वैल्यू का reference ले सकते हैं और उसे पढ़ सकते हैं या बदल सकते हैं, बिना उसकी Ownership को बदले। यह Rust को अधिक सुरक्षित और कुशल बनाता है, क्योंकि इससे मेमोरी की समस्याएँ नहीं होतीं।

References का परिचय (Introduction to References)

References Rust में उन pointers की तरह होते हैं जो मेमोरी की वैल्यू की ओर इशारा करते हैं, लेकिन Ownership को बदलते नहीं हैं। Reference के द्वारा आप वैल्यू तक पहुँच सकते हैं और उसका उपयोग कर सकते हैं, लेकिन आप उस वैल्यू के मालिक नहीं होते। इसे borrowing कहा जाता है, क्योंकि आप किसी वैल्यू को अस्थायी रूप से “उधार” लेते हैं।

सिंटैक्स (Syntax):

• &T : Immutable reference (वैल्यू को केवल पढ़ सकते हैं, बदल नहीं सकते)
• &mut T : Mutable reference (वैल्यू को पढ़ सकते हैं और बदल भी सकते हैं)

Immutable Borrowing (अपरिवर्तनीय Borrowing)

Immutable borrowing का उपयोग तब किया जाता है जब आप किसी वैल्यू को केवल पढ़ना चाहते हैं, न कि उसे बदलना। एक वैल्यू के कई immutable references हो सकते हैं, लेकिन जब कोई immutable reference होता है, तो उस वैल्यू का कोई mutable reference नहीं हो सकता।

उदाहरण:

fn main() {
    let s1 = String::from("नमस्ते");
    
    let s2 = &s1;  // s1 को उधार लिया, s2 अब s1 का reference है
    println!("s1: {}, s2: {}", s1, s2);  // s1 और s2 दोनों का उपयोग किया जा सकता है
}

इस उदाहरण में, s2 वैल्यू का एक immutable reference है, यानी यह केवल s1 की ओर इशारा करता है, लेकिन इसे बदल नहीं सकता। आप एक समय में कई immutable references बना सकते हैं।

Mutable Borrowing (परिवर्तनीय Borrowing)

Mutable borrowing का उपयोग तब किया जाता है जब आपको किसी वैल्यू को बदलने की आवश्यकता होती है। Rust में, एक समय में केवल एक ही mutable reference हो सकता है, और जब कोई mutable reference होता है, तो कोई और reference (immutable या mutable) नहीं हो सकता। यह नियम मेमोरी सुरक्षा को बनाए रखने में मदद करता है।

उदाहरण:

fn main() {
    let mut s1 = String::from("नमस्ते");

    let s2 = &mut s1;  // s1 का mutable reference लिया
    s2.push_str(", दुनिया!");  // s2 के माध्यम से s1 को बदल सकते हैं
    
    println!("{}", s2);  // स2 के द्वारा परिवर्तित वैल्यू प्रिंट की गई
}

इस उदाहरण में, s2 एक mutable reference है, और इसके द्वारा s1 की वैल्यू को बदला जा सकता है। ध्यान दें कि जब एक mutable reference मौजूद है, तब आप उसी वैल्यू का कोई दूसरा reference नहीं बना सकते।

Mutable और Immutable Borrowing का नियम (Rules for Mutable and Immutable Borrowing)

1. एक समय में कई Immutable References हो सकते हैं:
   • आप एक वैल्यू के कई immutable references बना सकते हैं, क्योंकि वे केवल पढ़ने की अनुमति देते हैं और डेटा को बदलते नहीं हैं।
2. एक समय में केवल एक Mutable Reference हो सकता है:
   • एक mutable reference के साथ आप वैल्यू को बदल सकते हैं, लेकिन एक समय में केवल एक ही mutable reference हो सकता है। इससे डेटा रेस (data race) जैसी समस्याएँ नहीं होतीं।
3. Immutable और Mutable References एक साथ नहीं हो सकते:
   • यदि एक वैल्यू का immutable reference है, तो आप उसी समय उस वैल्यू का mutable reference नहीं बना सकते, और इसके विपरीत। यह Rust में सुरक्षा का एक महत्वपूर्ण हिस्सा है।

उदाहरण:

fn main() {
    let mut s = String::from("नमस्ते");

    let r1 = &s;  // immutable reference
    let r2 = &s;  // दूसरा immutable reference
    println!("r1: {}, r2: {}", r1, r2);

    let r3 = &mut s;  // mutable reference (एरर)
    println!("r3: {}", r3);
}

इस उदाहरण में, r1 और r2 दोनों immutable references हैं और एक साथ मौजूद हो सकते हैं। लेकिन जैसे ही हम r3 में mutable reference बनाने की कोशिश करते हैं, Rust एरर देगा, क्योंकि immutable और mutable references एक साथ नहीं हो सकते।

Dangling References से बचाव (Avoiding Dangling References)

Rust का Ownership और Borrowing सिस्टम dangling references से बचाव करता है। एक dangling reference तब होता है जब आप किसी वैल्यू का reference लेते हैं लेकिन वह वैल्यू अब मेमोरी में मौजूद नहीं होती। Rust compile-time पर ही ऐसे मामलों को पकड़ लेता है, जिससे runtime errors नहीं होते।

उदाहरण (Dangling Reference का प्रयास):

fn main() {
    let reference_to_nothing = dangle();
}

fn dangle() -> &String {
    let s = String::from("नमस्ते");
    &s  // यह reference dangling होगा
}  // यहाँ s मेमोरी से हटा दिया जाएगा, लेकिन इसका reference अभी भी होगा

यह कोड Rust में compile नहीं होगा, क्योंकि s स्कोप से बाहर होते ही मेमोरी से हटा दिया जाएगा, और उसका reference काम नहीं करेगा। Rust ऐसे dangling references से बचाता है।

Lifetimes का परिचय (Introduction to Lifetimes)

Rust का Ownership और Borrowing सिस्टम मेमोरी सुरक्षा सुनिश्चित करता है, लेकिन कुछ स्थितियों में यह जानना जरूरी होता है कि कौन-सा reference कब तक वैध (valid) रहेगा। इसी को संभालने के लिए Rust में Lifetimes की अवधारणा होती है। Lifetimes यह सुनिश्चित करते हैं कि references हमेशा वैध रहें और कोई dangling reference (ऐसा reference जो वैल्यू के हटने के बाद भी मौजूद हो) न हो।

Lifetimes यह निर्धारित करते हैं कि किसी reference की validity (मान्य समय) कितने समय तक रहती है। Rust में हर reference के साथ एक lifetime जुड़ी होती है, जो बताती है कि reference का जीवनकाल कितना लंबा है। जब आप multiple references के साथ काम कर रहे होते हैं, तो Rust compile-time पर यह सुनिश्चित करता है कि कोई भी reference किसी वैध lifetime के बाहर उपयोग न हो।

Lifetimes की जरूरत क्यों है? (Why are Lifetimes Needed?)

Rust का borrowing सिस्टम references के साथ काम करता है, लेकिन कभी-कभी यह references का सही lifetime तय नहीं कर पाता। ऐसे मामलों में, compile-time पर Rust एरर देगा, जिससे प्रोग्राम में मेमोरी की सुरक्षा बनी रहे। Lifetimes को explicitly (स्पष्ट रूप से) परिभाषित करके हम Rust को यह बता सकते हैं कि references कब तक valid रहेंगे।

Dangling References से बचाव (Preventing Dangling References)

Lifetimes मुख्य रूप से dangling references से बचने के लिए उपयोग किए जाते हैं। एक dangling reference तब होता है जब कोई वैल्यू मेमोरी से हटा दी जाती है, लेकिन उसका reference अभी भी कहीं मौजूद होता है। Rust compile-time पर यह सुनिश्चित करता है कि ऐसा कभी न हो। Lifetimes references के valid रहने की अवधि को सीमित करते हैं, ताकि प्रोग्राम में कोई dangling reference न हो।

उदाहरण (Dangling Reference):

fn main() {
    let r;

    {
        let x = 5;
        r = &x;  // यहां r एक dangling reference बन जाएगा
    }

    println!("r: {}", r);  // एरर देगा क्योंकि x अब उपलब्ध नहीं है
}

इस उदाहरण में, जैसे ही x का स्कोप समाप्त होता है, वह मेमोरी से हटा दिया जाता है। लेकिन r अभी भी x का reference रखता है, जो अब मौजूद नहीं है। यह एक dangling reference की स्थिति बन जाती है, और Rust इसे compile-time पर एरर के रूप में पकड़ लेता है। Lifetimes ऐसी समस्याओं को रोकते हैं।

Lifetimes कैसे काम करते हैं? (How Do Lifetimes Work?)

Rust में हर reference के पीछे एक lifetime होती है, लेकिन ये ज्यादातर समय Rust द्वारा स्वतः निर्धारित (inferred) की जाती हैं। हालांकि, कुछ जटिल मामलों में आपको इसे manually specify करना पड़ता है। Lifetimes को angle brackets (<>) में लिखा जाता है और उन्हें एक सिंबल से दर्शाया जाता है, आमतौर पर यह सिंबल 'a होता है। यह lifetime को एक नाम देता है, ताकि इसे आप अपने कोड में references के साथ उपयोग कर सकें।

Syntax:

fn function_name<'a>(param: &'a T) {
    // कोड
}

यहाँ 'a lifetime को संदर्भित करता है, और यह बताता है कि फ़ंक्शन में param का reference कितने समय तक valid रहेगा। यह lifetime फ़ंक्शन के कॉलर पर निर्भर करता है, यानी फ़ंक्शन के कॉलर को यह सुनिश्चित करना होगा कि reference की validity 'a lifetime के भीतर ही हो।

Lifetimes का उदाहरण (Example of Lifetimes)

उदाहरण:

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

fn main() {
    let string1 = String::from("नमस्ते");
    let string2 = "दुनिया";

    let result = longest(&string1, &string2);
    println!("सबसे लंबा स्ट्रिंग है: {}", result);
}

इस उदाहरण में, हमने एक फ़ंक्शन longest परिभाषित किया है, जो दो string slices को लेता है और सबसे लंबा string slice रिटर्न करता है। यहाँ 'a एक lifetime है, जो यह सुनिश्चित करता है कि जो reference फ़ंक्शन से रिटर्न होगा, वह उसी lifetime के दौरान valid रहेगा जितनी देर तक input references valid हैं।

Lifetimes के प्रकार (Types of Lifetimes)

1. Implicit Lifetimes (अघोषित Lifetimes):
   • ज्यादातर मामलों में, Rust lifetimes को स्वचालित रूप से अनुमान लगाता है और आपको उन्हें explicitly परिभाषित करने की जरूरत नहीं होती। यह implicit lifetime कहलाता है।
2. Explicit Lifetimes (घोषित Lifetimes):
   • जब Rust यह तय नहीं कर पाता कि कौन-सा reference कितना लंबा valid रहेगा, तब आपको explicit रूप से lifetime को परिभाषित करना पड़ता है।

Multiple Lifetimes (कई Lifetimes)

कभी-कभी आपको एक फ़ंक्शन में कई references के साथ काम करना पड़ता है, और उन सभी की अलग-अलग lifetimes हो सकती हैं। ऐसे मामलों में, आप एक से अधिक lifetimes को नाम देकर परिभाषित कर सकते हैं।

उदाहरण:

fn multiple_lifetimes<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
    // कोड
}

इस उदाहरण में, 'a और 'b दो अलग-अलग lifetimes को दर्शाते हैं। आप कई references के साथ काम करते समय इस तरह से अलग-अलग lifetimes का उपयोग कर सकते हैं।

Static Lifetime (Static Lifetimes)

Rust में एक खास तरह का lifetime होता है, जिसे ‘static कहा जाता है। इसका मतलब है कि reference प्रोग्राम के पूरे runtime के दौरान valid रहेगा। Static lifetime का उपयोग तब होता है जब वैल्यू को पूरे प्रोग्राम के दौरान इस्तेमाल किया जा सकता है, जैसे कि string literals।

उदाहरण:

let s: &'static str = "यह एक स्टैटिक स्ट्रिंग है";

इस उदाहरण में, "यह एक स्टैटिक स्ट्रिंग है" एक string literal है, जिसका lifetime 'static है, क्योंकि यह पूरे प्रोग्राम के दौरान valid रहेगा।