Add functionality to the class RingBufferQueue from the previous section problem so that the queue resizes to an array twice as large when it runs out of space.
In other words, if asked to enqueue when the queue is full, it will enlarge the array to give it enough capacity.
For example, say our queue can hold 5 elements and we enqueue the five values 10, 20, 30, 40, and 50.
Our queue would look like this:
index 0 1 2 3 4
+----+----+----+----+----+
value | 10 | 20 | 30 | 40 | 50 |
+----+----+----+----+----+
^ ^
| |
head tail
If the client tries to enqueue a sixth element of 60, your improved queue class should grow to an array twice as large:
index 0 1 2 3 4 5 6 7 8 9
+----+----+----+----+----+----+----+----+----+----+
value | 10 | 20 | 30 | 40 | 50 | 60 | | | | |
+----+----+----+----+----+----+----+----+----+----+
^ ^
| |
head tail
The preceding is the simpler case to handle.
But what about if the queue has wrapped around via a series of enqueues and dequeues?
For example, if the queue stores the following five elements:
index 0 1 2 3 4
+----+----+----+----+----+
value | 40 | 50 | 10 | 20 | 30 |
+----+----+----+----+----+
^ ^
| |
tail head
If the client tries to add a sixth element of 60, you cannot simply copy the array as it is shown.
If you do so, the head and wrapping will be broken.
Instead, copy into the new array so that index 0 always becomes the new head of the queue.
The picture will look the same as the previous one with the value 60 at index 5.
Submit your completed and improved RingBufferQueue class.
It should have the same members as in the previous problem, but with the new resizing behavior added.
You may add new member functions to your class, but you should make them private.
Define the entire class including the class heading, the private member variables, and the declarations and definitions of all the public member functions and constructor.
