Meeting Room Scheduler

Meeting Room Scheduler

Interval booking across a pool of rooms — half-open intervals, first-fit allocation, and the calendar problem every backend engineer eventually ships.

Requirements

• Intervals are half-open: [s, e). Back-to-back meetings [1,5) and [5,8) do not conflict.
• Overlap test between [s1,e1) and [s2,e2): s1 < e2 && s2 < e1.
• First-fit policy: always the lowest-indexed conflict-free room.
• Bookings are permanent (no cancel in this version — it's the classic follow-up).

API to implement

Implement the class Scheduler. The I/O driver is already written in the starter code — it parses the command script below and calls your methods. You only implement the class.

| Command | Returns | Behavior | |---|---|---| | book <start> <end> | string | Book the interval [start, end) (start < end) in the lowest-indexed room where it doesn't overlap any existing booking. Return the room label (R0, R1, …) or REJECTED if no room is free. | | active <t> | int | How many meetings are in progress at time t (a meeting [s, e) is in progress when s ≤ t < e). |

Input format

The first line contains Q, the number of operations. The second line contains the constructor argument: numRooms — rooms R0 … R(numRooms-1). Each of the next Q lines is one command as listed above. String arguments contain no spaces.

Output format

For each command with a non-void return, print its result on its own line, in order. The driver does this for you — your methods just return values.

This is a design problem: the hidden tests exercise edge cases and interaction sequences, not performance tricks. Model the state cleanly and the tests will pass.

7
2
book 1 5
book 3 7
book 5 8
book 4 6
active 4
active 5
active 7

R0
R1
R0
REJECTED
2
2
1

5
1
book 0 10
book 10 20
book 9 11
active 9
active 10

R0
R0
REJECTED
1
1