Question bank — Queue — FIFO semantics, enqueue - dequeue, circular array implementation

True — since removal is strictly in arrival order, an element only waits behind those who arrived earlier, a fixed finite set; no later arrival can jump ahead, so no starvation. Contrast a Priority Queue where a low-priority item can starve.

True — because count distinguishes empty (0) from full (N), all N slots are usable. The one-slot-sacrifice trick is only needed when you refuse to store a count.

False — nothing moves; only the front index advances (with $\mathrm{mod}N$). Avoiding physical shifting is the entire reason the structure is O(1) per operation.

False — with front/rear pointers alone, front == rear means either empty or full; the two states are indistinguishable, which is exactly why we store count.

True — once the queue wraps, e.g. front=2, rear=0, the elements are physically split across the seam yet logically contiguous. Physical scatter, logical order intact.

False — they differ in which element leaves: a queue removes the oldest (FIFO), a stack removes the newest (LIFO). Swapping them turns a Breadth-First Search (BFS) into a depth-first search.

False — capacity only bounds how many can be held; the leave-order is fixed by arrival time regardless of N.

False — with the count scheme they are count==N and count==0; these can only coincide if N==0, a degenerate zero-capacity queue that holds nothing.

False — it is needed whenever front + count reaches or passes N, which can happen long before the queue is full (e.g. front=3, count=2, N=4 gives rear=1).

When front reaches N it indexes one past the last slot → out-of-bounds (or reads garbage). The fix is front = (front + 1) % N so the front wraps back to 0.

Yes — rear marches off the right end and the queue reports "full" while left slots sit empty; that is the classic drift/waste trap the circular design exists to kill.

The test is redundant and dangerous: front == rear is true for both empty and full, so it silently misclassifies states. Use count == N for full and count == 0 for empty and drop the pointer comparison.

The element is stored but invisible: rear is recomputed from the stale count, so the very next enqueue overwrites x, and dequeue never returns it. The count is the queue's memory of size.

No functional bug — clearing the slot is optional (it just drops the reference for garbage collection). The order is fine as long as you read the value before clearing.

rear is the next free slot, not an element; peek must return arr[front], the element that will leave next. Reading rear returns stale or None data.

A lone rear index makes empty and full both look like front == rear; count is a single unambiguous number (0 vs N) that resolves the collision cleanly.

The queue occupies count consecutive wrapping slots starting at front; the slot just past the last one is front + count, and $\mathrm{mod}N$ folds that back into [0, N) when it overshoots.

BFS must fully explore all nodes at the current distance before going deeper, and FIFO serves them in the exact order discovered; a stack (LIFO) would serve the newest first, diving deep instead of wide.

Each op touches only the front/count numbers and one array slot — a fixed amount of work independent of how many elements are stored, since nothing is shifted.

The wrap is fundamentally "position on a ring", which is precisely what $\mathrm{mod}N$ computes; the if branch is just $\mathrm{mod}N$ hand-coded, so the modulo states the intent directly and handles any overshoot uniformly. See Modular Arithmetic.

In the naïve non-wrapping array, "full" is tested by rear == N, which fires while the drifted-past left slots are empty; only wrapping (circular) reuses those slots.

It must raise/return an error (e.g. IndexError), never read arr[front], because that slot holds stale or None data and returning it would corrupt FIFO guarantees.

It must reject (raise OverflowError); otherwise rear would equal front and overwrite the oldest element, silently violating FIFO. A Circular Buffer / Ring Buffer sometimes chooses to overwrite, but a strict queue does not.

Yes — after one enqueue count=1=N (full); after dequeue count=0 (empty); rear = (front+1) % 1 = 0 always, and the single slot cycles correctly.

It is permanently full and empty simultaneously in the sense that count can never exceed 0; every enqueue must fail immediately. It's a degenerate but consistent case worth guarding explicitly.

At (N-1 + 1) % N = 0, i.e. it wraps to the start of the array — the exact seam the circular design was built to cross seamlessly.

rear = (1 + (N-1)) % N = N % N = 0, so it lands at index 0, filling the queue to count = N and demonstrating the last free slot is behind the front.

It rotates around the ring endlessly without drifting off the end — front and rear both advance $\mathrm{mod}N$, so the structure never "runs out" of the array, which is the whole payoff over the naïve version.