CS2201
Fall 2022
Assignment No. 2
Reminder: The Academic Honesty Policy posted on Brightspace is applicable to all work you do this semester in
CS2201.
Purpose: Gain experience in using and manipulating dynamic arrays, and the Law of the Big 3.
This assignment builds on our experience of implementing a tweet manager consisting of a collection of tweets using a
partially-filled array. In this assignment, we enhance our representation by removing the restriction of having a static array
and replacing it with a dynamic array. This allows our array to be of any size, with the added flexibility of us being able to
grow it if necessary.
Assignment: This assignment deals with an implementation of a tweet manager that stores a collection of tweets. In this
case, the tweets will be stored in a dynamic array. The tweets will be stored in sorted (chronological) order by their
timestamps. The size of the array will be specified by the user at runtime (with an appropriate default size), and in
addition we will allow the array to grow when needed. We are also enhancing the class by adding additional capabilities.
As with the prior project, not all elements of the array may contain useful tweets (i.e., we have a partially-filled array), we
need to keep track of the number of useful tweets actually stored in the array. The TweetMgr.h file describes all the
functions provided by the class.
The differences between this assignment and assignment #1 are as follows:
1. In this project, we will use dynamic arrays for holding the tweets, with the size of the array being set at run-time.
We will need to keep track of the size of the array at runtime.
2. Since our class now uses a dynamically allocated structure, it must provide functionality for the “Big 3”.
3. Since we can create arrays of any size, and even allocate new arrays during execution, we will never throw an
exception when our array becomes full – rather we will allocate a new larger array (filling it with the existing
data) and continue execution.
4. We are adding more functionality to the class.
The functional specification below will lead you through the steps necessary to convert your TweetMgr class from using a
static array to using a dynamic array. After that we will add additional functionality to the class, now that we have the
ability to grow the size of the array at runtime.
Like the previous assignment, the Tweet class has been provided to you. The properties of this class remain unmodified.
For questions on this classes, please refer to its description in the Project #1 specification. You should NOT make any
changes to the Tweet class.
TweetMgr class: The TweetMgr you are to implement will use a dynamic array of Tweet objects. A predetermined
default size of the dynamic array is defined by a constant called DEFAULT_SIZE. The TweetMgr class consists of the
dynamic array, a variable maxTweets that keeps track of the current size of the dynamic array, and a variable numTweets
that keeps track of the number of Tweet objects in the partially-filled array. You should store Tweets in the array in sorted
order (based on the sorted order of their timestamps) just as you did with the previous project.
Functional specifications: You will be supplied the class declaration file: TweetMgr.h. The file contains the declaration
of a set of methods to manipulate a TweetMgr object, which is simply a collection of Tweet objects.
Here are the new methods that you need to implement (there are some changes to existing methods too – those will be
noted later):
// Alternate constructor
// Create an empty collection (one with zero Tweets) but with an array of initSize
// elements
// Precondition: initSize > 0; throws std::invalid_argument exception if not the case
TweetMgr(size_t initSize);
// Copy constructor
TweetMgr(const TweetMgr &rhs);
// Assignment operator
const TweetMgr& operator= (const TweetMgr &rhs);
// Destructor
~TweetMgr();
// maxSize
// Return: size_t - the size of the Tweet array
size_t maxSize() const;
// merge(const TweetMgr& tm)
//
// Purpose: Merge a received tweet collection into this collection
// Parameters: TweetMgr tm (the TweetMgr collection to be merged)
// Return: None
//
// Behavior:
// 1. Add each tweet of the parameter TweetMgr to the object TweetMgr;
// may result in duplicate entries if both TweetMgrs had the same tweets.
// 2. All tweets that are added remain in the same order as they appeared in the
// parameter TweetMgr.
// 3. Any added tweet with the same timestamp of an existing tweet is added
// after (behind) the existing tweet.
// 4. If the total number of tweets is too big to be stored, we grow the array
// to a total size of the total number of tweets from the two collections plus
// DEFAULT_SIZE.
// 5. You are guaranteed that the parameter TweetMgr object tm is a different
// TweetMgr object than the ‘this’ TweetMgr object.
//
// Additional constraint: full credit will only be given for this function if it is
// efficient; that is only if each tweet is moved/assigned only once in the target
// array
void merge(const TweetMgr& tm);
// grow(size_t newSize)
//
// Purpose: grow the tweetArr array
// Parameters: newSize - the new desired size of the array
// Return: None
//
// If the current size of the array is equal to or larger than newSize, we do nothing.
// Else we allocate a new array for the TweetMgr of the desired size and copy the
// old data into it.
//
// NOTE: normally this method would be a private method, but it is public here to
// ease testing
void grow(size_t newSize);
To get started on this project, you are provided with a project2.zip file. This project2.zip file contains a CLion project that
has a TweetMgr.cpp file whose method bodies contain temporary junk code that you need to replace (just like project #1).
The project also contains a TweetMgr.h file that has several changes from project #1. The project as provided compiles
and runs, though it does not produce the correct results since all the method bodies contain temporary junk code. The
following instructions lead you through that process to create a correctly working class. These instructions will
incrementally add functionality to the project, a bit at a time. Making the changes in this fashion will allow you to compile
and test your intermediate steps – a key to success with this and any large, complex project. Please be sure to test each
step as you go.
Process:
1. Unzip the provided project2.zip and open the resulting project in the CLion IDE (wait for all progress bars to
complete before proceeding). Please review the instructions at the end of the project #0 spec on how to open a
provided CLion project. The code as provided will compile and run, though the test code will report errors since all
the class methods only hold temporary junk code. Replace the provided TweetMgrTest.cpp with the
TweetMgrTest.cpp from your project #1. The code should continue to compile and run, though all the tests should
continue to fail since the necessary functionality is still missing.
2. Open up TweetMgr.h and TweetMgr.cpp and review the provided code. Note the major changes in TweetMgr.h
which are:
a. The constant MAX_TWEETS has been replaced with maxTweets, a private instance variable of type size_t.
This instance variable will be used to keep track of the size of the dynamically allocated array, since the size
of the array can vary from one TweetMgr object to the next.
b. The constant DEFAULT_SIZE has been defined. It is type “const size_t” and has the value 50.
c. The tweetArr array is now a dynamic array rather than static array. I.e., it is declared as a TweetPtr. Note:
TweetPtr is defined at the top of TweetMgr.h and is equivalent to Tweet* (please see implementation
detail #16 below).
d. Note that numTweets still exists and will continue to hold the number of Tweets we’re actively storing in the
tweetArr.
e. There are a few more methods that are declared. We will address those later.
3. Open the TweetMgr.cpp file provided with this project and note that all the method bodies contain temporary junk
code. Next open the TweetMgr.cpp file from your project #1. One by one, copy-n-paste the bodies of the methods
from your project #1 file over to the methods in the project #2 file (do not overwrite the new method header
comments). Skip over any of the methods that are new for project #2. Take your time and make sure you copy all the
methods from your project #1 file. As you do this copying, ignore for now the red squiggly lines or messages that deal
with MAX_TWEETS.
4. After you have copied the method bodies, do a global find-replace in TweetMgr.cpp changing all instances of MAX_
TWEETS to maxTweets. Again, maxTweets is an instance variable that will keep track of the size of the dynamically
allocated array for that TweetMgr.
5. Change the default constructor to initialize an empty TweetMgr with a dynamically-allocated array of size
DEFAULT_SIZE (don’t forget to correctly initialize maxTweets and numTweets too). The constructor should use the
base member initialization list when possible.
At this point, you have a class that should behave almost identical to your project #1 class, except that this class uses
dynamic arrays rather than static arrays. Compile and run all your tests from project #1 (some students have stated that
their code would not compile without defining a destructor, but I have not found that to be the case). The only tests that
may fail would be those that depend upon the existence of a copy constructor or an assignment operator (a lot of your tests
may fail unexpectedly, depending upon how you wrote your test script – don’t let that worry you).
If all your testing is successful (besides the noted exceptions), you are ready to start adding new functionality to your
project. At this point, it would be good to review the grading feedback that you received on project #1 and address all the
issues identified. You will likely not have the feedback yet when you start this project, but you should come back and
complete this step as soon as the feedback is available.
If your testing is unsuccessful, make sure you address all the problems before you proceed or you may end up wasting a
lot of your time (you may want to add your Big-3 first before you spend much time debugging). As you add the following
functionality to your class, compile and test each method as you go. If you want, you can add private helper methods to
your class to support the work that you need to do (though that is not required, and I did not find it necessary).
6. Add the alternate constructor that takes an initial array size but still creates an empty TweetMgr. The constructor
should use the base member initialization list when possible.
7. Add the destructor to the class.
8. Add the copy constructor to the class. The constructor should use the base member initialization list when possible.
9. Add the assignment operator to the class. Use the “better way” discussed in class rather than the strategy of the text.
At this point, you have a class that now should behave identical to your project #1 class, except that this class uses
dynamic arrays rather than static arrays. Compile and run all your tests from project #1 – they should all succeed. Add
more tests to your TweetMgrTest.cpp program to fully test the four new methods added above. You do not need to test the
destructor explicitly, as it will be called on each & every TweetMgr object when it is destroyed. You can test your copy
constructor by declaring a new TweetMgr object and initializing it with another, or by passing a TweetMgr object to a
function using a pass-by-value parameter. The assignment operator will be called anytime you assign one TweetMgr
object to another TweetMgr object.
Now we are ready to add functionality to take advantage of the fact that we can create a larger array when we need it.
10. Write the maxSize() method. This method reports the size of the tweet array, rather than the number of tweets in the
collection. [Side note: normally we would not have such a method as a part of our external interface of the class, but
in this case it will ease the debugging/grading of your assignment.] Add code to TweetMgrTest.cpp to fully test your
maxSize() method.
11. Write the grow() method. Normally this would be a private method of the class – it is really not meant to be called by
the users of the TweetMgr class, rather it should only be used internally to the TweetMgr class – but we have made it
public to ease the testing/grading of the method. This method will allocate a larger dynamic array. Data must be
copied from the original array to the new array one element at a time. Make sure you do not have a memory leak. See
the provided header comments. Add code to TweetMgrTest.cpp to fully test your grow() method.
12. Modify the insert() method so that, rather than throwing an exception when we attempt to add a tweet to a full array,
we increase the size of the array to make room for the additional tweet. Whenever we need to grow the array in this
case, we will always double its existing size. See the provided header comments. Alter your code in
TweetMgrTest.cpp to fully test this new insert() method – since this method should no longer throw exceptions, you
will want to alter your try-catch blocks.
13. Write the merge() method. See the provided header comments for a description of this method. Rather than throwing
an exception when the total number of tweets is too big to be stored in the target array, we grow the size of the array
to make room for the additional tweets being merged. Whenever we need to grow the array in this case, we will make
it big enough to hold the total number of tweets after the merge plus an additional DEFAULT_SIZE entries. You
should only grow the array once, regardless of the number of tweets being merged. Also note the additional constraint
in the header comments: full credit is only given for an efficient implementation of this method. Add code to
TweetMgrTest.cpp to fully test your merge() method.
Implementation details: Here are a few notes that might be helpful:
14. Several methods of the TweetMgr class have parameters of type size_t (an unsigned integer type). The compiler may
give you conversion warning messages if you attempt to assign/compare such a parameter to a variable of type int. To
eliminate this particular warning, you should use variables of type size_t when appropriate or you can cast the value
of the size_t parameter to an int when necessary, or cast int values to size_t as appropriate. Your homework
submissions are expected to have clean compiles (no errors or warnings).
15. Since we are using a dynamic array in the TweetMgr class, the C++ compiler no longer takes care of creating/freeing
the array for you whenever a TweetMgr object is created/destroyed. Your code must be written to avoid sharing
arrays between distinct TweetMgr objects, and your code must be free of memory leaks.
16. The TweetMgr.h file declares the type TweetPtr to be equivalent to Tweet*. If you ever need to declare a pointer
to a Tweet, please use TweetPtr rather than Tweet*.
17. Please see Implementation Detail #9 in the project #0 spec and ensure that your project #2 CMakeLists.txt file has all
the correct compiler flags. Please also make sure that you are using the clang compiler. These are important to ensure
your code compiles when it is graded.
18. As with project #1, the methods that add & delete tweets from the collection are expected to do their work “in place”.
That means that they do all their work in the existing array inside the object. You will not receive full credit if you
create local temporary arrays or local temporary TweetMgr objects and then copy data to/from the array. Creating a
local temporary array or a local temporary TweetMgr object is only allowed when you’re required to have a new
array; i.e., in the assignment operator and the grow() method.
19. As with project #1, the array of Tweets used to represent the collection of tweets will be a partially-filled array. See
the information on partially-filled arrays in the project #1 spec. Note that you will lose points if your class methods do
unnecessary work; i.e., if you process elements of the array that are not currently being used to represent/store the
collection.
Final write-up: When you have completed the assignment, create a README document (a .txt text file or a .doc Word
document), and in it answer the following questions:
1. State your name and email address.
2. After reviewing this spec and the TweetMgr.h file, please estimate/report how many hours you think it will take you to
complete this project. [This is just an estimate and does not affect your grade.]
3. How many hours did you actually spend total on this assignment? [This information will not affect your grade.]
4. Did you encounter any impediments that prevented you from making progress on this assignment?
5. What did you like or hate about this assignment?
6. Do you have any suggestions for improving this assignment?
Submission for grading: When you have completed your work on this assignment, please submit these four files for
grading: TweetMgr.cpp, TweetMgr.h and TweetMgrTest.cpp, plus your final README write-up document. Submit
ONLY the four files; as you should not have changed any of the other source files. Please do not submit a zip file
containing your entire project. You can submit the files by visiting the assignment page in Brightspace (click on the
assignment name), scroll down to the “Submit Files” section, and add the files by clicking on the “Add a file” button and
finding the files to attach.
After submitting your homework, it is good practice to verify your submission. Revisit the assignment page in
Brightspace and make sure that your files were successfully submitted. Then click on each file to open it up so that you
can verify that you submitted the correct file, as opposed to some older version of the file. It is your responsibility to
insure the correctness of your submission.
Grading: This project is worth 50 points. Your grade on this project will be based on the following:
1. The correctness of your methods implemented in the TweetMgr.cpp file.
2. The efficiency of methods that have an efficiency requirement stated in the header comments.
3. The use of good programming style.
4. Eliminating redundancy in your code. If you fail to utilize other methods that you have written and have repeated
functionality in multiple methods, you will lose points.
5. The thoroughness of your testing performed in your TweetMgrTest program. Note: the thoroughness of your
testing often has a great impact on the correctness of your code (see item #1 above).
6. Appropriate responses to all questions in the README file.
Please post to Piazza if you find errors in this document or you feel something is missing or unnecessarily confusing.
You should also review the syllabus regarding the penalties for late programming assignments and for the course’s
academic honesty policy.
