need c++ format; here is start code; need .h and .cpp
---------------------------------------------------------------------------------------------------
#ifndef _ELASTICARRAY_H_
#define _ELASTICARRAY_H_
class ElasticArray{
public:
ElasticArray(int size);
int size() const { return _size; }
int& at(int i);
~ElasticArray();
private:
int* _array = nullptr;
int _size = 0;
};
#endif
--------------------------------------------------------------------------------------------------
#include"ElasticArray.h"
#include
#include
using namespace std;
ElasticArray::ElasticArray(int size)
{
if (size > 0)
{
_size = size;
_array = new int[size];
std::cout
}
else
_array = nullptr;
}
ElasticArray::~ElasticArray()
{
delete [] _array;
std::cout
}
int& ElasticArray::at(int i)
{
try{
if(i = _size)
throw std::out_of_range("Array index out of range.");
return _array[i];
}
catch(const char* a){
cout
}
}
------------------------------------------------------------------------------------------------------
ElasticArray Description When you are finished, the ElasticArray class will be able to do these things that the DynamicArray class could not do: ElasticArray will be default-constructable ElasticArray will be copy-constructable. ElasticArray will be copy-assignable and will exhibit correct "by-value" semantics. ElasticArray will implement o a push back() method that will allow new items to be added at the end of the array o front ( and back() methods that will allow the items at the front and back [respectively] of the array to be accessed. o a pop_back) method that will return the value of the item at the back of the array and then remove that item from the array. o a shrink to fit() method that will reduce the internal storage of the object to exactly match the current logical array size. Now we will look at some details about how to make each of these features a reality. Notice that we will not necessarily implement them in the order they are listed. Sometimes it is better to choose an order of implementation that will allow you more freedom to test and debug incrementally as you go along. Structural changes to ElasticArray attributes and existing methods The DynamicArray class that we used as a starting point was very simple and didn't have much overhead (just the_size attribute]. But in order to allow an array to grow/shrink efficiently at runtime, we will need to make a tradeoff between runtime performance in terms of speed (complexity] VS storage(overhead]. If we always keep our internal array exactly the same size as the number of elements it is storing, that means we will be doing an expensive in terms of time] re-size every time we add or remove an element The algorithm for a re-size (larger) is shown below To resize larger from orig size to new_size: 1. create a new array whose size is new_size 2. copy all elements from the current array into the new array 3. de-allocate the memory associated with the current array point the internal array pointer attribute to the new array 5. set the internal size attribute to the new size Note that this algorithm doesn't account for what value will be stored in the additional elements-you would need to carefully consider that implementation detail. Now imagine that this algoritm has to run every single time you add an item to the array. For very large arrays, you would spend a tremendous amount of time in the copy all elements from the current array into the new array step. This is too inefficient. It is often safe to assume that a "growing" array will continue to grow in the future [i.e. when you start adding items, you probably intend to add several). If we accept this assumption, and we are willing to temporarily "waste" a bit of space, we can reduce the total number of copy steps by pre-allocating a larger array than we currently need, and then partially filling it. When the internal storage array reaches its maximum capacity, we will allocate more space (again, pre-allocating more than we actually need). Based on that idea, let's say that we always allocate 10 elements at a time. That means that we reduce the amount of time spent copying elements to 1/10 of the original "perfect fit strategy. By pre-allocating larger "chunks" of space, we can reduce the copy overhead even more. The goal is to find a good balance between wasted space and wasted time. In practice, doubling the array size on every re-size operation tends to work pretty well (except for very large arrays). We will adopt that strategy here. But, if we are going to maintain a partially-filled array, we need at least one more attribute in our class-we need to know the current physical size (available storage) as well as the current logical size [how much are we really usingl. ElasticArray Description When you are finished, the ElasticArray class will be able to do these things that the DynamicArray class could not do: ElasticArray will be default-constructable ElasticArray will be copy-constructable. ElasticArray will be copy-assignable and will exhibit correct "by-value" semantics. ElasticArray will implement o a push back() method that will allow new items to be added at the end of the array o front ( and back() methods that will allow the items at the front and back [respectively] of the array to be accessed. o a pop_back) method that will return the value of the item at the back of the array and then remove that item from the array. o a shrink to fit() method that will reduce the internal storage of the object to exactly match the current logical array size. Now we will look at some details about how to make each of these features a reality. Notice that we will not necessarily implement them in the order they are listed. Sometimes it is better to choose an order of implementation that will allow you more freedom to test and debug incrementally as you go along. Structural changes to ElasticArray attributes and existing methods The DynamicArray class that we used as a starting point was very simple and didn't have much overhead (just the_size attribute]. But in order to allow an array to grow/shrink efficiently at runtime, we will need to make a tradeoff between runtime performance in terms of speed (complexity] VS storage(overhead]. If we always keep our internal array exactly the same size as the number of elements it is storing, that means we will be doing an expensive in terms of time] re-size every time we add or remove an element The algorithm for a re-size (larger) is shown below To resize larger from orig size to new_size: 1. create a new array whose size is new_size 2. copy all elements from the current array into the new array 3. de-allocate the memory associated with the current array point the internal array pointer attribute to the new array 5. set the internal size attribute to the new size Note that this algorithm doesn't account for what value will be stored in the additional elements-you would need to carefully consider that implementation detail. Now imagine that this algoritm has to run every single time you add an item to the array. For very large arrays, you would spend a tremendous amount of time in the copy all elements from the current array into the new array step. This is too inefficient. It is often safe to assume that a "growing" array will continue to grow in the future [i.e. when you start adding items, you probably intend to add several). If we accept this assumption, and we are willing to temporarily "waste" a bit of space, we can reduce the total number of copy steps by pre-allocating a larger array than we currently need, and then partially filling it. When the internal storage array reaches its maximum capacity, we will allocate more space (again, pre-allocating more than we actually need). Based on that idea, let's say that we always allocate 10 elements at a time. That means that we reduce the amount of time spent copying elements to 1/10 of the original "perfect fit strategy. By pre-allocating larger "chunks" of space, we can reduce the copy overhead even more. The goal is to find a good balance between wasted space and wasted time. In practice, doubling the array size on every re-size operation tends to work pretty well (except for very large arrays). We will adopt that strategy here. But, if we are going to maintain a partially-filled array, we need at least one more attribute in our class-we need to know the current physical size (available storage) as well as the current logical size [how much are we really usingl
