Implement a Custom Rc (Reference Counting) in Rust

This challenge asks you to implement a simplified version of Rust's Rc (Reference Counting) smart pointer. Rc is fundamental for sharing immutable data between multiple parts of your program without resorting to complex ownership transfers or unsafe code. Understanding how it works is crucial for managing memory and preventing data races in concurrent scenarios.

Problem Description

Your task is to create a generic smart pointer struct, let's call it MyRc<T>, that allows multiple owners of an immutable value of type T. MyRc<T> should internally manage a reference count. When a new MyRc instance is created pointing to the same data, the reference count should increment. When a MyRc instance goes out of scope, the reference count should decrement. If the reference count drops to zero, the owned data should be deallocated.

Key Requirements:

1. Generic Type T: MyRc<T> should be able to hold any type T.
2. Immutable Access: MyRc<T> should provide immutable access to the contained data T.
3. Reference Counting:
   • When a MyRc is cloned, the reference count must increase.
   • When a MyRc is dropped, the reference count must decrease.
   • When the reference count reaches zero, the inner data T must be deallocated.
4. Clone Trait: MyRc<T> must implement the Clone trait.
5. Drop Trait: MyRc<T> must implement the Drop trait to handle deallocation.
6. Dereferencing: MyRc<T> should allow dereferencing using the * operator to access the inner T value. This will require implementing the Deref trait.

Expected Behavior:

• Creating MyRc::new(value) should initialize the reference count to 1.
• Cloning an MyRc should produce a new MyRc pointing to the same data and increment the count.
• Dropping MyRc instances should correctly decrement the count.
• The underlying data T should only be dropped when the last MyRc pointing to it is dropped.

Important Considerations:

• You will need to store both the data T and the reference count.
• Since MyRc allows multiple owners, the data T and the reference count will need to be managed in a way that is accessible by all clones. A common approach is to use an allocation on the heap.
• Consider how to handle the deallocation of T safely.

Examples

Example 1:

use std::rc::Rc; // For comparison, not for direct use in your solution

let rc1 = MyRc::new(5);
let rc2 = MyRc::clone(&rc1); // Or MyRc::new(5) if MyRc::new implicitly clones

println!("rc1: {}, rc2: {}", *rc1, *rc2);
// Expected Output:
// rc1: 5, rc2: 5

Explanation: Two MyRc instances, rc1 and rc2, are created pointing to the same integer value 5. Cloning rc1 creates rc2 and increments the internal reference count. Dereferencing allows printing the value.

Example 2:

struct MyStruct {
    value: i32,
}

impl Drop for MyStruct {
    fn drop(&mut self) {
        println!("Dropping MyStruct with value: {}", self.value);
    }
}

let rc1 = MyRc::new(MyStruct { value: 10 });
let rc2 = MyRc::clone(&rc1);

// rc1 goes out of scope here
// The MyStruct should NOT be dropped yet because rc2 still holds a reference.
{
    let rc3 = MyRc::clone(&rc1);
    println!("rc3 value: {}", rc3.value);
    // rc3 goes out of scope here
    // The MyStruct should STILL NOT be dropped.
}
// rc2 goes out of scope here
// Now the MyStruct should be dropped, and the "Dropping MyStruct..." message should be printed.

Expected Output (order of print statements matters):

Dropping MyStruct with value: 10

Explanation: This example demonstrates that the MyStruct is only dropped when the last MyRc instance referencing it goes out of scope. The Drop implementation for MyStruct is called exactly once.

Constraints

• Your MyRc<T> struct should be generic over T.
• You cannot use std::rc::Rc or std::sync::Arc in your implementation of MyRc<T>.
• You may use standard Rust library features like Box for heap allocation and Cell or RefCell if you need interior mutability for the reference count itself (though a Cell<usize> is usually sufficient for the count).
• Performance: While not strictly timed, your implementation should be reasonably efficient, mirroring the typical performance characteristics of reference counting.

Notes

• Think about where the data T and the reference count should live. A common pattern for shared ownership is to put both into a heap allocation.
• Consider how to handle the Clone implementation. It needs to duplicate the pointer to the shared data and increment the count.
• The Drop implementation for MyRc<T> is critical. It must decrement the count and, if the count becomes zero, deallocate the inner data T.
• Implementing Deref will be necessary to allow *my_rc_instance syntax.