Bird
Raised Fist0
DSA Goprogramming~5 mins

Queue Implementation Using Array in DSA Go - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: Queue Implementation Using Array
O(n)
Understanding Time Complexity

We want to understand how the time taken by queue operations changes as the number of elements grows.

How does adding or removing items from a queue using an array affect performance?

Scenario Under Consideration

Analyze the time complexity of the following queue operations implemented with an array.


package main

import "fmt"

type Queue struct {
    items []int
}

func (q *Queue) Enqueue(val int) {
    q.items = append(q.items, val)
}

func (q *Queue) Dequeue() int {
    val := q.items[0]
    for i := 0; i < len(q.items)-1; i++ {
        q.items[i] = q.items[i+1]
    }
    q.items = q.items[:len(q.items)-1]
    return val
}

func main() {
    q := Queue{}
    q.Enqueue(1)
    q.Enqueue(2)
    fmt.Println(q.Dequeue())
}
    

This code adds items to the end and removes from the front of an array-based queue.

Identify Repeating Operations

Look at what repeats when we add or remove items.

  • Primary operation: Adding to the end (append) and removing from the front (slice update)
  • How many times: Each enqueue or dequeue runs once per operation, but dequeue shifts the array slice which can copy elements
How Execution Grows With Input

Adding items grows smoothly, but removing items requires shifting elements.

Input Size (n)Approx. Operations for Dequeue
10About 9 moves
100About 99 moves
1000About 999 moves

Pattern observation: Dequeue operation cost grows linearly with the number of items because elements shift left each time.

Final Time Complexity

Time Complexity: O(n) for Dequeue, O(1) amortized for Enqueue

Removing an item takes longer as the queue grows, but adding is fast on average.

Common Mistake

[X] Wrong: "Both enqueue and dequeue are always O(1) because arrays are fast."

[OK] Correct: Removing from the front requires shifting all other elements, which takes time proportional to the queue size.

Interview Connect

Understanding these costs helps you explain why some queue implementations use linked lists or circular buffers for better performance.

Self-Check

"What if we used a circular array with front and rear pointers instead of slicing? How would the time complexity change?"

Practice

(1/5)
1. What is the main characteristic of a queue implemented using an array?
easy
A. It allows random access to elements
B. It follows Last-In-First-Out (LIFO) order
C. It follows First-In-First-Out (FIFO) order
D. It stores elements in sorted order

Solution

  1. Step 1: Understand queue behavior

    A queue adds elements at the rear and removes from the front, so the first element added is the first removed.
  2. Step 2: Match behavior with options

    This behavior is called First-In-First-Out (FIFO), which matches It follows First-In-First-Out (FIFO) order.
  3. Final Answer:

    It follows First-In-First-Out (FIFO) order -> Option C
  4. Quick Check:

    Queue = FIFO [OK]
Hint: Queue means first in, first out order [OK]
Common Mistakes:
  • Confusing queue with stack (LIFO)
  • Thinking queue allows random access
  • Assuming queue sorts elements automatically
2. Which of the following is the correct way to declare a fixed-size queue array of size 5 in Go?
easy
A. var queue [5]int
B. queue := []int{5}
C. queue := [5]int
D. queue := make([]int, 5)

Solution

  1. Step 1: Understand array declaration in Go

    Fixed-size arrays in Go are declared with var name [size]type, e.g., var queue [5]int.
  2. Step 2: Check options for fixed-size array

    var queue [5]int uses var queue [5]int which is correct fixed-size array syntax.
  3. Final Answer:

    var queue [5]int -> Option A
  4. Quick Check:

    Fixed array = var name [size]type [OK]
Hint: Fixed array uses var name [size]type in Go [OK]
Common Mistakes:
  • Using make for fixed-size array (make is for slices)
  • Using slice literal with size inside braces
  • Confusing slice and array syntax
3. Consider this Go code snippet implementing a queue using an array and two indices front and rear:
var queue [5]int
front, rear := -1, -1

// Enqueue 10
rear++
queue[rear] = 10

// Enqueue 20
rear++
queue[rear] = 20

// Dequeue
front++

// Enqueue 30
rear++
queue[rear] = 30

// Current queue elements from front+1 to rear are printed
What will be the printed queue elements?
medium
A. [20, 30]
B. [10, 20, 30]
C. [10, 30]
D. [30]

Solution

  1. Step 1: Trace enqueue and dequeue operations

    Initially front = -1, rear = -1. Enqueue 10: rear=0, queue[0]=10 Enqueue 20: rear=1, queue[1]=20 Dequeue: front=0 (removes queue[0]=10) Enqueue 30: rear=2, queue[2]=30
  2. Step 2: Identify current queue elements

    Queue elements are from front+1=1 to rear=2, so queue[1]=20 and queue[2]=30. Printed elements: [20, 30]
  3. Final Answer:

    [20, 30] -> Option A
  4. Quick Check:

    After dequeue, front=0; elements = queue[1..2] = [20,30] [OK]
Hint: Queue elements lie between front+1 and rear indices [OK]
Common Mistakes:
  • Printing elements from 0 to rear ignoring front
  • Not updating front after dequeue
  • Confusing front and rear indices
4. Given this Go code snippet for dequeue operation in a queue implemented with array:
func dequeue() int {
    if front == rear {
        fmt.Println("Queue is empty")
        return -1
    }
    front++
    return queue[front]
}
What is the main bug in this code?
medium
A. It does not check if queue is full before dequeue
B. It should decrement rear instead of front
C. It increments front before returning element, causing off-by-one error
D. It returns queue[front] after increment, which is correct

Solution

  1. Step 1: Understand dequeue logic

    Dequeue removes element at front+1 index. Incrementing front before returning queue[front] is correct to get the next element.
  2. Step 2: Analyze options for bug

    It does not check if queue is full before dequeue is unrelated to dequeue. It increments front before returning element, causing off-by-one error says increment causes off-by-one error but this is standard for queue. It should decrement rear instead of front is wrong because rear is for enqueue. It returns queue[front] after increment, which is correct correctly states the code is correct.
  3. Final Answer:

    It returns queue[front] after increment, which is correct -> Option D
  4. Quick Check:

    Increment front then return element = correct dequeue [OK]
Hint: Dequeue increments front then returns element [OK]
Common Mistakes:
  • Thinking front should not be incremented before return
  • Confusing enqueue and dequeue pointers
  • Checking full condition in dequeue
5. You have a fixed-size queue implemented using an array of size 5 with front and rear indices initialized to -1. After performing these operations:
Enqueue 5
Enqueue 10
Enqueue 15
Dequeue
Dequeue
Enqueue 20
Enqueue 25
Enqueue 30
Enqueue 35
What will happen when you try to enqueue 35, and what is the correct way to handle this situation?
hard
A. Queue underflow occurs; reset front and rear to -1
B. Queue overflow occurs; use circular queue logic to reuse space
C. Queue accepts 35 without issue; no special handling needed
D. Queue overflow occurs; increase array size dynamically

Solution

  1. Step 1: Trace queue operations and indices

    Initial front = -1, rear = -1 Enqueue 5: rear=0 Enqueue 10: rear=1 Enqueue 15: rear=2 Dequeue: front=0 (removes 5) Dequeue: front=1 (removes 10) Enqueue 20: rear=3 Enqueue 25: rear=4 Enqueue 30: rear=5 (array size 5, index 5 invalid - overflow) Trying to enqueue 35 causes overflow
  2. Step 2: Explain correct handling

    Since front has moved forward, space at start is free but rear reached end. Using circular queue logic allows rear to wrap to start and reuse space. Without circular logic, overflow occurs prematurely.
  3. Final Answer:

    Queue overflow occurs; use circular queue logic to reuse space -> Option B
  4. Quick Check:

    Overflow at end; circular queue fixes space reuse [OK]
Hint: Use circular queue to avoid overflow when space is free [OK]
Common Mistakes:
  • Ignoring free space at start after dequeues
  • Assuming array can grow dynamically
  • Resetting front and rear incorrectly
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard