Hello,

I have been working on this c++ assignment, I have completed all the functions on card_functs.cpp for problems 4-9, however, I am getting errors when compiling the file card_functs.cpp. I also need help creating the tests for the functions on card_functs-test.cpp and test_yourself.cpp.

Thank you

CS 111 - Spring 2021 - Homework 4 p. 6 of'? ' It asks the user for the name of as le, assumed to have the structure of a le created by save_cards. ' It uses Problem 8's function read_size to read the number of sets of ash card information in that le, and uses what read_size returns to declare an array of FlashCard instances of that size. ' It uses Problem 9's rnction readicards to read that le's ash card information into that new array of FlashCard instances. It loops through that array of now-lled FlashCard instances at least one time, such that, for each FlashCard instance, it: prints to the screen the front data eld value of that ash card, and asks the user to enter the correct value they think should be in its back data eld increments the time sitested data eld for that FlashCard instance if what the user entered does match the correct back data eld value for that FlashCard instance, the program should print a message saying so to the screen, and increment the times_correct data eld for that FlashCard instance; ...but if not, it JU ST prints to the screen a message saying so, and also printing what the correct back data eld value actually is. ' Before the end, call Problem 6's di splayicards to let the user see how they have done so far on this set of ash cards. ' When done, use Problem 7's function save_cards to overwrite the contents of the le originally read from (while you will be rewriting the same front and back data elds for each FlashCard instance, you will also now be writing newly-updated time s_tested and, hopellly, time s_corre ct values for these ash cards.) optional variations ' Your program can start by asking if the user wants to enter ash cards, or use existing cards from a le. This would give a chance to use Problem 5's entericards function - if the user wants to enter cards, your program would ask how many they wish to create, declare an array of ash cards of that size, and then ll it using read_cards. (In this case, you'd want to also ask for a le name to use function save_cards to save their results in after the test run(s).) ' Your program can go more than one "round" of testing through the array; you could go a number of times you determine, or you could ask the user how many rounds they want to do, or you could keep asking if they want to do another round, etc. ' Your program can go through the cards in a different order you could play with the CH rand rnction to go in a different order, for example. Or on subsequent \"rounds" it might only reask cards that the user has never gotten right yet, or that they have only gotten right a particular number of times, or that have been tested least 'equently, etc. ' At the end, you could compute and print out summary statistics based on the timesitested and timesicorrect data elds of these ash cards. (You are welcome to add additional useful mctions to cardfuncts . Cpp and card functs . h just be sure to include the usual opening comment block for each, and add appropriate tests for them in card- functs-test . Cpp.) CS 111 Spring 2021 - Homework4 p. 4 of 7 - on the rst line: JUST the number of ash cards in that array ' then, for each FlashCard instance in that array, write its front value, back value, times tested, and times correct on a single line, separating those four values by blanks ' (and, for good style, closes its input le stream when done!) ...and returns either nothing (return type of void) or some other value if you prefer. (I considered having it return a bool, so it could return true if it succeeded, and false if, for example, the function could not open the desired le name for writing, BUT decided to leave this as an OPTION if you are interested.) In card functs .h, put the lnction header for save_cards after the header for function display_cards, but before the #endif in that le! And, in the main function in card functstest . app, after your tests so far for the previous problems, add at least two testing calls of save_cards, such that: ' ...you also print out, before each call of save_cards, a message to the screen saying what le should be created, and a brief description of what should be in it. - (It is perfectly ne for these calls of save_cards to use the atleasttwoarraysofFlashCardinstances you already created for testing previous problems!) Problem 8 - function read_size - 10 points You have probably guessed that eventually I am going to ask you to write a function that reads from a le (such as that created by Problem 7's function saveioards) into an array of FlashCard instances. And, you would be correct about that. BUT, when we want to use that function in a moregeneral situation, it will be less complicated if we provide a little additional helper function rst. So, in le cardfuncts . opp, after the function saveicards, develop a function read_size. Be sure to put an opening comment block before read_size with the usual signature, purpose, and tests sections! Function readisize expects just a desired le name, assumed to have the structure of a le created by saveicards. It has the sideeffects of trying to open that le and read the value on its rst line as an integer, (for good style, then closing its output le stream), and it tries to return the integer it hopefully read. In cardfuncts .h, put the function header for read_size aer the header for function save_cards, but before the #endif in that le! And, in the main mction in card functstest . app, after your tests so far for the previous problems, add at least two testing calls of read_size. ' Here, you can just print a message that you are testing read_si 26, and print to the screen the result of comparing what each of those example calls of read_size returns to what they should return! - (And you have at least two lovely example les from testing Problem 7 that you should be able to use for those tests!) \fCS 111 - Spring 2021 Homework 4 p. 3 of"? Problem 6 - function display_cards - 10 points Testing Problems 4 and 5 properly would be easier with a function that DISPLAYS the ash cards in within an array of ash cards, though! So, in le cardfuncts . cpp, after the function entericards, develop a function display_cards. Be sure to put an opening comment block before displayicards with the usual signature, purpose, and tests sections! Function di splay_cards expects an array of FlashCard instances and its size, has the side-effects of: tastefully printing to the screen, for each ash card in the given array: its front value, its back value, its times tested, and its times correct, ...inc1uding a version of the data eld name before each (as in Week 4 Lecture 2's posted example print_movie . app), and printing a blank line after each ash card's information, _._and returns either nothing (return type of void) or some other value if you prefer. In card-functs . h, put the rnction header for display_cards after the header for function enter_cards, but before the #endif in that le! And NOW it is reasonable to start a testing main function in a le cardfunctstest. cpp! For Problems 4 through 6, this main should include: ' declarations of at least two arrays of FlashCard instances of derent sizes ' at least two example calls of entericards to enter example values into those arrays at least two example calls of display_cards to display the contents of those arrays after the calls to entericards. (When I tested my versions of these, I prompted the user with what to enter for each test, and then printed a message saying they should see those contents plus Os displayed afterwards. BUT as long as your array sizes are not too large, I think it is okay to let the user enter what they wish, and print to the screen a message before the calls to di splay_cards noting that they SHOULD see the values they entered, with Os for times tested and correct.) Problem 7 - function save_cards - 10 points To allow a user to save their ash cards between testing sessions, being able to save their info to a le would be very useful! So, in le cardfuncts . app, after the function display_cards, develop a function save_cards. Be sure to put an opening comment block before saveicards with the usual signature, purpose, and tests sections! Function save_cards expects a desired file name, an array of FlashCard instances, and its size, has the side-eects of trying to write, to a le with that desired le name: CS 111 - Spring 2021 - Homework4 p. 5 of? Problem 9 - function read_cards - 10 points And, we do want a function to read saved ash card information from a le into an array of ash card instances. So, in le card-functs . cpp, after the function readisize, develop a rnction read_cards. Be sure to put an opening comment block before readicards with the usual signature, purpose, and tests sections! Function read_cards expects a desired le name, assumed to have the structure of a le created by saveicards, an array of FlashCard instances, and its size, has the sideeffects of: trying to open that le for reading (and reading past the size) (nice additional touch: compare the size read to the array size provided, and complain and exit if they do not match! But I will let you decide if you wish to do check that or not.) ' reading in the ash card information in the le to each FlashCard instance in the passed array (thus actually changing the argument array) ' (and, for good style, closing its output le stream when done!) ...and returns either nothing (return type of void) or some other value if you prefer. (I considered having it return a bool, so it could return true if it succeeded, and false if, for example, the mction could not open the desired le name for writing, BUT decided to leave this as an OPTION if you are interested.) In card functs . h, put the lnction header for readicards after the header for function readisize, but before the #endif in that le! And, in the main function in card functstest . cpp, after your tests so far for the previous problems, add at least two testing calls of read_cards, such that: ' you declare two new arrays of FlashCard instances to be used in these tests (although they can be convenientlysized to work with the output les created by the previous tests of save_cards) ' after your testing calls of save_cards, you print to the screen a brief description what should now be in these newlylled new arrays of FlashCard instances, ...then call di splay_cards for each of these newlylled new arrays of FlashCard instances to show that readichards worked. Submit your les cardfuncts . cpp, cardfuncts . h, cardfunctstest . cpp, and the atleasttwo example les you saved test arrays of FlashCard instances to (make sure these les have a sufx of . txt, so that Canvas will accept them!). Problem 10 - a little test-yourself application! - 17 points Finally, create a different main function in a le named testyourself . cpp, that uses an array of FlashCard instances and these mctions to write a little application program that lets the user test themselves using a set of these ash cards. Here are the minimum requirements for this application (and you can extend it in various ways from here IF you wish