// TODO: Fill in as necessary template class Queue { private: std::vector _data; size_t_head, _tail; static T _sentinel; public static const int MAX_DISP_ELEMS = 100; Queue(size_t size); static void set_sentinel(const T& elem) { _sentinel = elem; } static T get_sentinel() { return _sentinel; } bool is empty() const; size_t size() const; void resize(size_t size); const T& peek() const; bool dequeue(); bool enqueue (const T& elem); std::string to_string(size_t limit = MAX_DISP_ELEMS) const; friend class Tests; // Don't remove this line }; template T Queue::_sentinel = TO; template Queue::Queue(size_t size) { // TODO} // TODO - Fill in the missing implementations. Experiment with the aesthetics by moving // some of these implementations inline into your class def above). See which gives // you more readable code. #endif 1* Queue_h This queue has a sentinel. When peek() is invoked on an empty queue, you must return the sentinel instead of throwing an exception. What about the value of the sentinel? Well, there's no way you can tell what it is, because its type is only known at compile time from your actual template parameter. So you simply provide a facility to allow the user of your class to set the sentinel to whatever value they deem is illegal in their set of elements. If I use your Queue to create my own queue of integers, I might instantiate it thus: Queue my_queue (100); Queue::set_sentinel (0); if (my_queue.peek () == 0) { Your first miniquest - Constructor Implement: template Queue::Queue (size_t size); The constructor needs to size the data element correctly, and set initial values for the_head and _tail members. It doesn't matter that you set them to any specific values. Only that the values are consistent across multiple queue operations. The constructor is not the place to set the sentinel, which is a static member. In fact, only the user of your Queue class is responsible for setting the sentinel. You don't have to worry about it at all. Your second miniquest - Enqueue Implement: template bool Queue::enqueue(const T& elem); If the queue is not already full, insert a copy of the given element into the end of the queue and return true. Otherwise (if full) return false. Your third miniquest - Dequeue Implement: template bool Queue:dequeue(); If the queue is not empty, remove the (front) element and return true. Otherwise (if empty) return false. Where is this dequeued (popped) element? It's not returned to you. That's correct. Please discuss possible reasons why a programmer might choose to make methods like Stack::pop() or Queue::dequeue() not return the removed element. Your fourth miniquest - Peek Implement: template const T& Queue:-peek() const; Return a copy of the front element in the queue (without changing it). Why do we need it? Or...do we need it? Your fifth miniquest - Is Empty Implement: template bool Queue:is_empty() const; Please check in our subreddit or ask if you don't know what to do here. Your sixth miniquest - Resize Implement: template void Queue:resize(size_t size); Whoo! Biggie. I don't know about you, but the best way I've found to resize3 a queue like this one is to create a brand new queue and dequeue everyone off the old queue and enqueue them in the new queue, in order. See if you can find a cheaper way to do the same thing. Remember that if the old queue has more elements than can fit in the new one, some of the latecomers may have to be booted. Yeah. That's too bad. Your seventh miniquest-Popalot Implement the global (non-instance) method: template void popalot(Queue& q); Thought I'd give you guys another easy freebie. Just implement a global scope template method (not instance or class method - what's the difference?) with the above signature. All it has to do is to clear the queue by emptying it. Do it however you want. But the queue I give you should be empty when I get it back. Your eighth miniquest - To string As usual, to_string) is all about attention to detail. The two examples below hopefully shed enough light on how the queue is to be serialized. 4 Implement: template string Queue::to_string(size_t lim) const; This method should return a string that looks like in Figure 2: # Queue - size = {SIZE reported by your size () method)-/ data : {_data[_head]} {_data[...]} {etc. up to limit) Figure 2-output of to_string(size_t limit) The enter key character (-) stands for a single newline. Portions between curly braces (also in red) must be replaced by you. There are spaces where they're obviously there in the above pic. There are none where you wouldn't put them. Amore concrete example (Figure 3): + Queue - size - 2 data : four five Figure 3: A Queue of size 2 with the items "four' and 'five" The line that starts with data should list the items in the queue. The rest of the line after the colon may be empty. If there are more than limit items, you must print the first limit items followed by a space and a single token of 3 periods (...) in place of everything else. Finally, note that data, above, denotes the data in the queue from the user's perspective. Not the queue's underlying_data element (See Figure 4). Your ninth miniquest - Queue of Objects You don't have to do anything special here. All your previous miniquests were with integers. If your templating works as expected, it should succeed on non-integer types as well. I'll test that bit here and you get a freebie reward just for doing things a particular way. Cool! How long is a well written solution? Well-written is subjective, of course. But I think you can code up this entire quest in about 150 lines of clean self-documenting code (about 25-50 chars per line on average), including additional comments where necessary. You can use the provided starter code as one example of acceptable code density