Manage Tasks with Priority and Task-ID Execution Rules

### Problem Implement a task manager that stores tasks belonging to users. Each live task has a task ID, a user ID, and a priority. A user may own multiple tasks. Preserve the following class interface and behavior: - `TaskManager(tasks)` initializes the system from triples `[userId, taskId, priority]`. - `add(userId, taskId, priority)` adds the specified task. Its task ID is guaranteed not to exist currently. - `edit(taskId, newPriority)` changes that existing task's priority without changing its owner. The task ID is guaranteed to exist. - `rmv(taskId)` removes the specified existing task. The task ID is guaranteed to exist. - `execTop()` removes and executes the highest-priority task across all users. Break a priority tie by choosing the greatest task ID. Return that task's **user ID**. If there are no tasks, return `-1`. ```cpp class TaskManager { public: TaskManager(vector<vector<int>>& tasks); void add(int userId, int taskId, int priority); void edit(int taskId, int newPriority); void rmv(int taskId); int execTop(); }; ``` ### Examples The examples list calls to this class. `null` denotes construction or a `void` method, not an additional return value in the C++ API. **Example 1:** ```text Input: operations = ["TaskManager","execTop","edit","execTop","execTop","execTop"] arguments = [[[[7,20,4],[3,25,4],[7,22,2]]],[],[22,9],[],[],[]] Output: [null,3,null,7,7,-1] Explanation: Tasks 20 and 25 initially tie at priority 4, so task 25 executes and returns its owner 3. Editing task 22 to priority 9 makes it execute next, returning 7. Task 20 then also returns owner 7. The final call finds no tasks. ``` **Example 2:** ```text Input: operations = ["TaskManager","rmv","execTop","add","add","execTop","edit","execTop","execTop"] arguments = [[[[2,10,0]]],[10],[],[9,10,5],[1,11,5],[],[10,0],[],[]] Output: [null,null,-1,null,null,1,null,9,-1] Explanation: Removing task 10 empties the system. Task ID 10 can then be added for user 9 because it no longer exists. At priority 5, task 11 executes before task 10 because its ID is greater, returning user 1. After task 10 is edited to priority 0, it executes and returns user 9. The system is empty again. ``` ### Constraints - `1 <= tasks.length <= 100000` initially. - `0 <= userId, taskId <= 100000`. - `0 <= priority, newPriority <= 10^9`. - At most `200000` calls are made in total to `add`, `edit`, `rmv`, and `execTop`. - Inputs and method calls have valid task IDs under the stated existence guarantees. ### Clarifying Questions - Does a larger user ID win a tie? No. Compare task IDs after comparing priorities. - Does `execTop()` return a task ID? No, it returns the selected task's user ID. - Does execution keep the task available? No, execution removes it. - Can priority be zero? Yes. - Can a removed ID be added later? Yes, provided it is absent when `add` is called; the guarantee concerns current membership. ### What a Strong Answer Covers - Preserves all five class entry points, including the three `void` methods and persistent state across calls. - Implements the exact priority and task-ID tie rules while returning the correct owner. - Handles edits, explicit removals, execution removals, multiple tasks per user, and empty-system calls consistently. - Gives operation bounds that support the full call limit. ### Follow-up Questions - What must remain true after editing a task to its current priority? - How should removing a task and later reusing its ID affect future execution results? ```hint Keep live membership and ranking consistent One view can locate a task by ID, while another orders live tasks by priority and then task ID. Every operation must update both views consistently. ```