Circular Queue Implementation Using Array in DSA Rust - Time & Space Complexity

Time Complexity: Circular Queue Implementation Using Array

O(1)

Understanding Time Complexity

We want to understand how the time taken by circular queue operations changes as the queue size grows.

Specifically, how fast can we add or remove items in this circular queue?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

struct CircularQueue {
    data: Vec<i32>,
    front: usize,
    rear: usize,
    size: usize,
    capacity: usize,
}

impl CircularQueue {
    fn enqueue(&mut self, value: i32) {
        if self.size == self.capacity { return; }
        self.data[self.rear] = value;
        self.rear = (self.rear + 1) % self.capacity;
        self.size += 1;
    }

    fn dequeue(&mut self) -> Option<i32> {
        if self.size == 0 { return None; }
        let val = self.data[self.front];
        self.front = (self.front + 1) % self.capacity;
        self.size -= 1;
        Some(val)
    }
}
    

This code adds (enqueue) and removes (dequeue) elements in a circular queue using an array.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Single-step index updates and assignments in enqueue and dequeue.
• How many times: Each enqueue or dequeue runs once per call, no loops inside.

How Execution Grows With Input

Each enqueue or dequeue operation does a fixed number of steps regardless of queue size.

Input Size (n)	Approx. Operations
10	5 steps per operation
100	5 steps per operation
1000	5 steps per operation

Pattern observation: The time per operation stays the same no matter how big the queue is.

Final Time Complexity

Time Complexity: O(1)

This means adding or removing an item takes the same short time no matter how many items are in the queue.

Common Mistake

[X] Wrong: "Because the queue uses an array, enqueue or dequeue must take longer as the queue grows."

[OK] Correct: The circular queue uses fixed index moves without shifting elements, so each operation stays quick regardless of size.

Interview Connect

Understanding constant-time queue operations shows you know how to manage data efficiently, a key skill in many coding challenges.

Self-Check

"What if we replaced the array with a linked list? How would the time complexity of enqueue and dequeue change?"

Practice

1. What is the main advantage of using a circular queue over a simple linear queue when implemented using an array?

easy

A. It efficiently uses all available space by wrapping around the array.

B. It allows storing different data types in the same queue.

C. It automatically sorts the elements in the queue.

D. It uses less memory than a linear queue.

Solution

1. Step 1: Understand linear queue limitation

   In a linear queue using an array, once the rear reaches the end, no more elements can be added even if there is free space at the front.

2. Step 2: Circular queue advantage

   A circular queue connects the end of the array back to the front, allowing reuse of empty spaces and efficient use of the array.

3. Final Answer:

   It efficiently uses all available space by wrapping around the array. -> Option A

4. Quick Check:

   Circular queue = efficient space use [OK]

Hint: Circular queue reuses space by wrapping indices [OK]

Common Mistakes:

• Thinking circular queue sorts elements
• Believing it uses less memory than linear queue
• Assuming it stores different data types

2. Which of the following Rust code snippets correctly initializes a circular queue array of size 5 with front and rear pointers set to -1?

easy

A. let mut queue: [i32; 5]; let front: i32; let rear: i32;

B. let queue = Vec::new(); let front = 0; let rear = 0;

C. let mut queue: [i32; 5] = [1; 5]; let mut front: usize = 0; let mut rear: usize = 0;

D. let mut queue: [i32; 5] = [0; 5]; let mut front: i32 = -1; let mut rear: i32 = -1;

Solution

1. Step 1: Check array initialization

   let mut queue: [i32; 5] = [0; 5]; let mut front: i32 = -1; let mut rear: i32 = -1; initializes a fixed-size array of 5 integers with all zeros, which is correct for a circular queue.

2. Step 2: Check front and rear initialization

   let mut queue: [i32; 5] = [0; 5]; let mut front: i32 = -1; let mut rear: i32 = -1; sets front and rear to -1, indicating the queue is empty, which is standard practice.

3. Final Answer:

   let mut queue: [i32; 5] = [0; 5]; let mut front: i32 = -1; let mut rear: i32 = -1; -> Option D

4. Quick Check:

   Correct array and pointers initialization = let mut queue: [i32; 5] = [0; 5]; let mut front: i32 = -1; let mut rear: i32 = -1; [OK]

Hint: Initialize array with zeros and front/rear as -1 [OK]

Common Mistakes:

• Using Vec instead of fixed-size array
• Not initializing front and rear to -1
• Leaving variables uninitialized

3. Consider this Rust code snippet for a circular queue of size 5. After these operations, what is the state of the queue array?

let mut queue = [0; 5];
let mut front: i32 = -1;
let mut rear: i32 = -1;

// Enqueue 10
if rear == -1 {
    front = 0;
    rear = 0;
    queue[rear as usize] = 10;
} else {
    rear = (rear + 1) % 5;
    queue[rear as usize] = 10;
}

// Enqueue 20
rear = (rear + 1) % 5;
queue[rear as usize] = 20;

// Dequeue
front = (front + 1) % 5;

// Enqueue 30
rear = (rear + 1) % 5;
queue[rear as usize] = 30;

medium

A. [10, 20, 30, 0, 0]

B. [0, 20, 0, 30, 0]

C. [10, 20, 0, 30, 0]

D. [0, 0, 20, 30, 0]

Solution

1. Step 1: Trace enqueue and dequeue operations

   Initially front = -1, rear = -1, queue = [0,0,0,0,0]. - Enqueue 10: front=0, rear=0, queue[0]=10 -> [10,0,0,0,0] - Enqueue 20: rear=(0+1)%5=1, queue[1]=20 -> [10,20,0,0,0] - Dequeue: front=(0+1)%5=1 (10 removed logically) - Enqueue 30: rear=(1+1)%5=2, queue[2]=30 -> [10,20,30,0,0]

2. Step 2: Determine final queue state

   Queue array is [10, 20, 30, 0, 0]. Although 10 is logically dequeued, it remains in the array until overwritten.

3. Final Answer:

   [10, 20, 0, 30, 0] -> Option C

4. Quick Check:

   After dequeue, front moves, old value stays [OK]

Hint: Remember dequeue moves front, old data stays until overwritten [OK]

Common Mistakes:

• Assuming dequeued elements are erased immediately
• Not applying modulo for rear and front
• Mixing up front and rear positions

4. The following Rust code for enqueue in a circular queue has a bug. What is the error?

fn enqueue(queue: &mut [i32; 5], front: &mut i32, rear: &mut i32, value: i32) {
    if (*rear + 1) % 5 == *front {
        println!("Queue is full");
        return;
    }
    if *rear == -1 {
        *front = 0;
        *rear = 0;
    } else {
        *rear = (*rear + 1) % 5;
    }
    queue[*rear as usize] = value;
}

medium

A. The condition to check if queue is full is incorrect.

B. The initial check for empty queue should be *front == -1, not *rear == -1.

C. The queue array should be mutable but is not.

D. The modulo operation should use queue length minus one.

Solution

1. Step 1: Analyze empty queue check

   The code checks if *rear == -1 to detect empty queue, but standard practice is to check if *front == -1 because front indicates the start of queue.

2. Step 2: Understand impact of wrong check

   If *rear == -1 but *front is not -1, the queue might be incorrectly treated as empty, causing logic errors.

3. Final Answer:

   The initial check for empty queue should be *front == -1, not *rear == -1. -> Option B

4. Quick Check:

   Empty queue check uses front pointer [OK]

Hint: Empty queue means front == -1, not rear [OK]

Common Mistakes:

• Checking rear instead of front for empty queue
• Incorrect modulo usage
• Not passing mutable references properly

5. You have a circular queue of size 4 implemented using an array. Initially, front = 2 and rear = 1 (meaning the queue is full). You perform one dequeue operation followed by two enqueue operations with values 50 and 60. What will be the final positions of front and rear pointers?

hard

A. front = 3, rear = 3

B. front = 3, rear = 0

C. front = 3, rear = 1

D. front = 2, rear = 3

Solution

1. Step 1: Understand initial full queue state

   Queue size = 4, front = 2, rear = 1 means the queue is full because (rear + 1) % size == front ( (1+1)%4=2 ).

2. Step 2: Perform dequeue operation

   Dequeue moves front forward: front = (2 + 1) % 4 = 3. Rear remains 1.

3. Step 3: Perform first enqueue (50)

   rear = (1 + 1) % 4 = 2, insert 50 at index 2.

4. Step 4: Perform second enqueue (60)

   rear = (2 + 1) % 4 = 3, insert 60 at index 3.

5. Final Answer:

   front = 3, rear = 3 -> Option A

6. Quick Check:

   After dequeue and two enqueues, pointers wrap correctly [OK]

Hint: Update front on dequeue, rear on enqueue with modulo [OK]

Common Mistakes:

• Not applying modulo after pointer increment
• Confusing front and rear updates
• Assuming queue is empty after dequeue