Stack Using Linked List vs Array Stack Trade-offs in DSA Rust - Compare & Choose

Challenge - 5 Problems

🧠 Conceptual

intermediate

Memory Usage Difference Between Linked List Stack and Array Stack

Which statement best describes the memory usage difference between a stack implemented using a linked list and one using a fixed-size array?

A Both linked list and array stacks use fixed memory sizes that cannot change during runtime.

B Array stack uses memory dynamically and can grow as needed, while linked list stack uses a fixed amount of memory regardless of usage.

C Linked list stack uses memory dynamically and can grow as needed, while array stack uses a fixed amount of memory regardless of usage.

D Linked list stack uses less memory than array stack because it stores fewer elements.

💡 Hint

Think about how each structure allocates memory when elements are added.

A linked list stack allocates memory for each new element dynamically, so it grows as needed. An array stack allocates a fixed block of memory upfront, which may be larger than needed or may limit growth.

❓ Predict Output

intermediate

Output of Push Operations on Array Stack

What is the printed state of the stack after pushing elements 10, 20, and 30 onto an array-based stack with capacity 5?

DSA Rust

struct ArrayStack {
    data: [i32; 5],
    top: usize,
}

impl ArrayStack {
    fn new() -> Self {
        ArrayStack { data: [0; 5], top: 0 }
    }

    fn push(&mut self, val: i32) {
        if self.top < 5 {
            self.data[self.top] = val;
            self.top += 1;
        }
    }

    fn print_stack(&self) {
        for i in (0..self.top).rev() {
            print!("{} -> ", self.data[i]);
        }
        println!("null");
    }
}

fn main() {
    let mut stack = ArrayStack::new();
    stack.push(10);
    stack.push(20);
    stack.push(30);
    stack.print_stack();
}

A 30 -> 10 -> 20 -> null

B 30 -> 20 -> 10 -> null

C null

D 10 -> 20 -> 30 -> null

💡 Hint

Remember that stack is Last In First Out (LIFO).

The last pushed element (30) is on top, so it prints first, followed by 20 and then 10.

❓ Predict Output

advanced

Output of Pop Operations on Linked List Stack

Given a linked list stack with elements pushed in order 5, 15, 25, what is the printed state after two pop operations?

DSA Rust

struct Node {
    val: i32,
    next: Option<Box<Node>>,
}

struct LinkedListStack {
    head: Option<Box<Node>>,
}

impl LinkedListStack {
    fn new() -> Self {
        LinkedListStack { head: None }
    }

    fn push(&mut self, val: i32) {
        let new_node = Box::new(Node { val, next: self.head.take() });
        self.head = Some(new_node);
    }

    fn pop(&mut self) -> Option<i32> {
        if let Some(node) = self.head.take() {
            self.head = node.next;
            Some(node.val)
        } else {
            None
        }
    }

    fn print_stack(&self) {
        let mut current = &self.head;
        while let Some(node) = current {
            print!("{} -> ", node.val);
            current = &node.next;
        }
        println!("null");
    }
}

fn main() {
    let mut stack = LinkedListStack::new();
    stack.push(5);
    stack.push(15);
    stack.push(25);
    stack.pop();
    stack.pop();
    stack.print_stack();
}

A 5 -> null

B 15 -> 5 -> null

C null

D 25 -> 15 -> 5 -> null

💡 Hint

Pop removes the top element each time.

After pushing 5, 15, 25, the stack top is 25. Two pops remove 25 and 15, leaving 5 on top.

🧠 Conceptual

advanced

Performance Trade-off in Push Operation Between Linked List and Array Stack

Which statement correctly describes the time complexity and performance trade-off of the push operation in linked list stack versus array stack?

A Both linked list and array stack push operations have O(n) time complexity due to memory allocation.

B Linked list stack push operation is O(n) because it needs to traverse the list, while array stack push is always O(1).

C Array stack push operation is O(n) because it shifts elements, while linked list push is O(1).

D Both linked list and array stack push operations have O(1) time complexity, but array stack may require resizing which can cause occasional slower pushes.

💡 Hint

Consider how arrays resize and how linked lists add nodes.

Linked list push is always O(1) as it adds a node at the head. Array stack push is usually O(1), but resizing the array when full causes O(n) time occasionally.

🚀 Application

expert

Choosing Stack Implementation for Unknown Maximum Size

You need to implement a stack for a program where the maximum number of elements is unknown and can grow very large. Which implementation is the best choice and why?

A Use a linked list stack because it can grow dynamically without a fixed size limit.

B Use an array stack with a large fixed size to avoid resizing overhead.

C Use an array stack with a small fixed size and reject pushes when full.

D Use a linked list stack but pre-allocate all nodes to improve speed.

💡 Hint

Think about flexibility and memory usage when size is unknown.

A linked list stack grows dynamically as needed, making it suitable when maximum size is unknown. Fixed-size arrays risk overflow or wasted memory.

Practice

1. Which of the following is a key advantage of using a linked list to implement a stack compared to using an array?

easy

A. Faster access to elements by index

B. Simpler to implement in all languages

C. Uses less memory overall

D. Dynamic size without needing to resize

Solution

1. Step 1: Understand stack size behavior

   Arrays have fixed size or require resizing, linked lists grow dynamically as needed.

2. Step 2: Compare access and memory

   Linked lists do not provide faster index access and may use more memory due to pointers.

3. Final Answer:

   Dynamic size without needing to resize -> Option D

4. Quick Check:

   Linked list stacks grow dynamically = B [OK]

Hint: Linked list stacks grow dynamically, arrays need resizing [OK]

Common Mistakes:

• Thinking linked lists have faster index access
• Assuming arrays always use less memory
• Believing linked lists are simpler to implement everywhere

2. Which Rust syntax correctly declares a stack using a vector (array stack)?

easy

A. let stack: Vec<i32> = [];

B. let stack = new Vec<i32>();

C. let mut stack: Vec<i32> = Vec::new();

D. let mut stack = Vec<i32>::empty();

Solution

1. Step 1: Recall Rust vector initialization

   Correct syntax uses Vec::new() to create an empty vector.

2. Step 2: Check each option

   B uses invalid 'new' keyword, C uses array syntax, D uses non-existent empty() method.

3. Final Answer:

   let mut stack: Vec<i32> = Vec::new(); -> Option C

4. Quick Check:

   Vec::new() creates empty vector = A [OK]

Hint: Use Vec::new() with mut for stack vector in Rust [OK]

Common Mistakes:

• Using 'new' keyword instead of Vec::new()
• Trying to assign array literal directly
• Using non-existent Vec methods

3. What will be the output of the following Rust code using a linked list stack?

struct Node {
    value: i32,
    next: Option,
}

fn main() {
    let mut stack: Option = None;
    // Push 10
    stack = Some(Box::new(Node { value: 10, next: stack }));
    // Push 20
    stack = Some(Box::new(Node { value: 20, next: stack }));
    // Pop top
    if let Some(top) = stack {
        println!("{}", top.value);
        stack = top.next;
    }
    // Print new top
    if let Some(top) = &stack {
        println!("{}", top.value);
    }
}

medium

A. 20
10

B. 10
20

C. 10
10

D. 20
20

Solution

1. Step 1: Trace push operations

   Push 10: stack points to node with value 10. Push 20: stack points to node with value 20, next points to 10.

2. Step 2: Trace pop and prints

   Pop prints 20, then stack moves to next node (10). Next print prints 10.

3. Final Answer:

   20 10 -> Option A

4. Quick Check:

   Stack top after push: 20, after pop: 10 [OK]

Hint: Top is last pushed, pop removes top, next is previous [OK]

Common Mistakes:

• Confusing push order and print order
• Printing after pop without updating stack
• Misunderstanding Option and Box usage

4. Identify the bug in this Rust code implementing a stack with an array (Vec) and fix it:

fn main() {
    let mut stack: Vec<i32> = Vec::new();
    stack.push(1);
    stack.push(2);
    let top = stack.pop();
    println!("Top element: {}", top.unwrap());
    println!("Next element: {}", stack.pop().unwrap());
    println!("Empty pop: {}", stack.pop().unwrap());
}

medium

A. Calling unwrap() on empty pop causes panic; check Option before unwrap

B. Vec::new() should be Vec::with_capacity()

C. Use stack.peek() instead of pop() to view top

D. stack.push() should be called after pop()

Solution

1. Step 1: Analyze pop calls and unwrap

   First two pops succeed, third pop returns None; unwrap on None panics.

2. Step 2: Fix by checking Option before unwrap

   Use if let or match to safely handle empty stack before unwrap.

3. Final Answer:

   Calling unwrap() on empty pop causes panic; check Option before unwrap -> Option A

4. Quick Check:

   Pop returns Option, unwrap on None panics [OK]

Hint: Always check Option before unwrap after pop [OK]

Common Mistakes:

• Ignoring possibility of empty stack pop
• Thinking Vec::with_capacity fixes panic
• Using peek instead of pop changes logic

5. You need to implement a stack in Rust for a program where the maximum number of elements is unknown and can grow large unpredictably. Which implementation is better and why?

1. Array stack using Vec with occasional resizing
2. Linked list stack with dynamic nodes

hard

A. Array stack is better because it uses less memory per element and faster cache access

B. Linked list stack is better because it grows dynamically without resizing overhead

C. Array stack is better because resizing never happens in Rust Vec

D. Linked list stack is better because it uses contiguous memory for faster access

Solution

1. Step 1: Consider unknown large size and growth

   Linked list stacks grow node by node without resizing, arrays resize which can be costly.

2. Step 2: Compare memory and speed trade-offs

   Arrays have better cache but resizing overhead; linked lists avoid resizing but use extra memory per node.

3. Step 3: Choose best fit for unpredictable large growth

   Linked list avoids resizing delays and can handle unpredictable growth smoothly.

4. Final Answer:

   Linked list stack is better because it grows dynamically without resizing overhead -> Option B

5. Quick Check:

   Dynamic growth without resizing = Linked list stack [OK]

Hint: For unknown large size, linked list avoids resizing delays [OK]

Common Mistakes:

• Assuming Vec never resizes
• Ignoring memory overhead of linked list nodes
• Confusing contiguous memory with linked list