in C++ A Mad Lib is a phrasal template word game in which a player is prompted for a list of words to substitute into blanks in a pre-written short story. The story, with the blanks filled in, is then usually read aloud, resulting in nonsensical, surrealistic, and often hilarious result. The original concept is attributed to Roger Price and Leonard Stern, of golden age TV fame it was a simpler time As a programming project, MadLibs provide a good opportunity to exercise basic programming skills, again often with hilarious results (hopefully from the proper output, rather than from the code itself). In particular, the MadLibs assignment requires significant programming involving: 1. Non-Formatted, Line-oriented Text Input/Output 2. String processing 3. Using classes from the Standard Template Library 4. And, of course, basic programmatic technique. The Assignment Description You are to write a C++ program which loads a MadLib from an existing text file. The program must process the input text file, locating specially formatted template fields (templateField) embedded within the pre-written story (the storyText). For each templateField, the program will prompt the user for an appropriate substitution value (substValue) and save the response. After substValues for all templateFields have been entered by the user, the program must assemble the complete story, replacing the templateFields with the corresponding substValues, combining with the original storyText, and printing the complete (-ly hilarious) story to the console screen. Problem Analysis: Assignment #1: This is an intermediate complexity project. Before you begin, you must have a good understanding of the problem before you begin. What substitutions are allowed? How are they specified? What does the input file look like? This is your first assignment a problem analysis of the MadLib problem itself: a written functional design of the problem with complete pseudocode for the program. In simplest terms, a functional design should result in a list of function descriptions, detailing for each the inputs, outputs, and purpose of each function, as well as pseudocode which describes the overall program flow in the context of these functions. The most difficult part of such an analysis for intro students is the idea that you can use functions to describes parts of the design which are not yet fully understood that this part of the functional design process itself. Program Description This section is a broad not detailed - overview of the phases of the program, describing it as a processing engine which converts a specially formatted file a MadLib file along with user inputs, into hilarious output displayed on the console. Following this broad overview, detailed specifications for the file layout will be given. Overview: Locating and Loading a Madlib File Your program must allow a MadLib text file to be specified on the command line, and if the filename is not present on the command line, your program must prompt the user to enter the filename explicitly. Alternatively, the selection of Madlib files can be implemented as a menu of files in a specific folder, which would also be specified on the program command line. (Note: this requirement may be changed. At minimum, the filename on the command line is required and should be one of the first things you get worked out). If the input MadLib file is not found, or is incorrectly formatted in ANY way, you must print out an error message identifying the filename, the line number on which the file was determined to be invalid (or actually print the line that was invalid). Overview: MadLib File Analysis Overview Once properly located and opened, the MadLib file must be read line-by-line. Each line must be analyzed to locate all the templateFields embedded that line of storyText. Each templateField must be inspected and classified as either predefined or userdefined , and stored for later usage. The storyText section will end with line containing only a special templateField which is reserved to mark the end of the story. Following this special end-of-story marker is a final section, containing descriptions for user-defined templateFields. This section must also be analyzed to load appropriate descriptions for the user-defined templateFields. The analysis of the MadLib file should locate all substitutions that must be made, and verify that the file is formatted properly. The results of analysis should be, primarily, a list of substitutions that must be made by the user. Storage for these substitutions is NOT left up to your discretion; rather, you must use a std::map storage container to manage the substitutions. The std::map container will be discussed in class. Overview: User Substitution Entry Following analysis of the MadLib file, you will have a list of templateFields for which the user must enter text substation values (substValues). At this point, the user must be prompted for each substitution. Substitutions should be read as simple line-oriented, non-formatted text input. No validation of the input is required except to ensure that the user does enter nonempty, non-whitespace substitution text. You must handle Input failure conditions at this point (though with non-formatted input, the only likely input failure would be end-of-file, implying the user pressed CTRL-Z during input. End-of-file should be treated as a signal to abort all input and terminate the program immediately. The substitution entry phase of the program uses the templateFields located during analysis as a starting point. For each, the appropriate description must be printed, and the user allowed to input the required substValue. The user's substitution text must be stored along with the substitutions, in the same std::map container. NOTE: substValues for ALL templateFields must be entered and stored before any part of the storyText is assembled and output to the screen. The effect then, will be that the user selects a file, and is immediately prompted to enter substValues. Obviously, the Madlib file is read and analyzed between these two phases, but from the users perspective, this is not noticeable. Overview: File Second Pass, Story Re-Assembly After all substValues have been entered by the user, the program will make a second pass through the MadLib file. During this second pass, the program must again read the file line-by-line and locate the templateFields. However, this time each templateField located must be replaced with the corresponding substValue, in-line within the story text. This yields the correctly reassembled output text of the story. Two notes here One: Convert all substValues to UPPERCASE so they will show "boldly" in the output this is a requirement. The other note should be obvious: Do NOT modify the MadLib file during this phase replacements should be made to an in-memory copy of each line, not to the actual input file! Each resulting line of output, with all templateFields replaced, may then printed to the screen as soon as it is complete. Obviously, much of the programming is the same as the first pass, so similar in fact, that you should seriously consider how to reuse the same code to accomplish both passes. There is a minor difference between 1st and 2nd pass file analysis and usage. During 1st pass, blank lines can be ignored, as can leading, embedded, and trailing whitespace. However, during 2nd pass, blank lines and spaces are significant and must be preserved and displayed. The MadLib file Second Pass performs substitutions into the storyText, producing modified lines of text that are then displayed to the hysterically laughing user. A "Pause" should follow the output, after which the program must allow the user to either select another MadLib file (if in menu mode) or Exit the program. MadLib File Detailed Specification Perhaps the MOST important element of this program is the MadLib file itself. If you do not understand how the MadLib file is organized, you will not succeed. Thus, we will look at several, and we will talk it through in design sessions, in class . This is the current specification for the MadLib files: 1) MadLib files must be pure ASCII text files. 2) All MadLibs will have an extension type *.madlib. Thus, a valid MadLib filename is ToBeOrNotToBe.madlib. NOTE: While this is specified, the extension is not a program requirement. Do not reject files with other extensions. 3) All MadLib Files contain free form lines of text, delimited by newlines. Thus, Notepad or any programming editor can create these files. Word Processor files (.doc,.docx) are NOT allowed. 4) Any line starting with the '#' hash character (after removing leading whitespace) is considered a comment line, and must be skipped. Comment lines can be anywhere in a MadLib file. 5) All MadLib files contain at LEAST a storyText section. a. The StoryText section contains free form lines of text. b. Within each line of StoryText there may be zero or more embedded templateFields. c. templateFields are described in the Template Fields Detailed Specification section of this document. 6) All MadLib storyText sections MUST be ended with an EndOfStory marker. a. The EndOfStory marker is a special text token that must be on a separate line following the storyText. No other text may be on the EndOfStory marker's line. Note that the EndOfStory marker should start at the left edge of the line, but this is not a requirement, so it will be necessary to remove and ignore any leading whitespace. b. The EndOfStory marker's VALUE is "@end-of-story@" (no quotes, case-insensitive). 7) Following the EndOfStory marker, MadLib files may contain an optional user-defined Descriptions section. a. The user-defined Descriptions section provides appropriate descriptions with which to prompt the user for a user-defined templateFields. b. If no user-defined templateFields were found in the StoryText, this section may be omitted. However, it may be present because of templateFields that did not end up in the story. Thus, there may be descriptions for templateFields that were not found this should not be considered an error. You may either store these descriptions or discard them, as the will not be used. Note: it might be useful to output an error message describing this situation, something like "Description 'blah-blah-blah' found for unused templateField '@Bob@'. c. All user-defined templateFields that were found in the storyText must have a matching entry in this section. If a matching description is not found, the file is invalid an appropriate error message must be displayed ("Template field @BlahBlah@ missing description Invalid MadLib file!"), and the program terminated without displaying the story. NOTE: However, the entire description section should still be processed before terminating the program. This ensures that if multiple error messages for this situation occur, they will all be identified to the user. d. Each line of the user-defined Descriptions contains one templateField followed by one or more whitespace characters, followed by a non-empty text description which ends at the end of line. For Example: i. @BE@\t A Special Verb e. Leading whitespace before the templateField on each line must be ignored. f. Leading and Trailing whitespace on the description itself must be ignored and removed. g. Thus, for the example above, the description for @BE@ would be "A Special Verb", note that tab, newline, leading and trailing, but not embedded, spaces have been removed. Template Field (templateField) Detailed Specification Template fields as specially formatted text tokens that identify blanks within storyText that must be replaced by substValues entered by the user. The format of these templateFields is best introduced with a simple example: To @BE@ or not to @BE@, That is the @noun@ The underlined parts of this line are all properly formatted templateFields. Specifically, the format for templateFields is as follows: @templateIdent@ The '@' characters are required, and the templateIdent must be pure, non-whitespace, ASCII text. Note: templateIdent refers to the actual identifier or token between the '@' symbols, while a templateField is the entire sequence, including both '@' characters and the enclosed templateIdent. However, in this document, the two terms are often used interchangeably. templateIdents are case-insensitive, thus @BE@ is the same templateField as @be@ or @Be@. TemplateFields may not split lines. If a TemplateField starts on a line, the templateIdent and its ending '@' must be on the same line. Failure to find a terminating '@' implies the MadLib file is invalid and should be handled with an appropriate error message and program termination. TemplateIdents must consist of pure ASCII text containing only alphanumeric (non-case-sensitive) characters, and Underscores (_). Note: obviously, these are the same as valid C++ identifiers, so you shouldn't be confused too much! Examples: @BE@ is valid @BE AFRAID@ is not, as it contains whitespace @BE_AFRAID@ is valid. Note: It is permissible to relax the rules for templateIdents to allow for embedded spaces and special characters this may make certain aspects of delimiting templateFields somewhat simpler. TemplateIdents come in two varieties, predefined and userDefined. These are discussed in the following sections Predefined TemplateIdents/TemplateFields Predefined templateIdents identify the standard parts of speech that MadLibs are made from. The following list is all the pre-defined templateIdents (shown as valid templateFields) and the appropriate description that should be used to prompt the user for each. During the substitution entry phase of the program, every predefined templateField must be given a unique substValue by the user. Predefined TemplateIdent / TemplateField Description / User Prompt Explanation (perhaps used to hint to the user) @noun@ A Noun Person, place, or thing @nouns@ or @pnoun@ A Plural Noun Same, but with s @verb@ A Verb An action or state @ptverb@ A Past-Tense verb Past-tense of the action or state (do => did, ride=>rode) @adj@ or @adjective@ An Adjective Describes a noun, like "two nails" or "tiny finger" @adv@ or @adverb@ An Adverb Describes verb, adj,or adverb often ending in ly "very hungry" "quickly" "really tiny" @excl@ or @exclamation@ An Exclamation "GadZooks!" "Holy Crap, Batman!" "YowZah!", or for the Brits, "I Say, Old Chap!" UserDefined TemplateIdents/TemplateFields UserDefined templateIdents are used to identify template fields that don't fall into the normal MadLib categories. Essentially, any templateIdent not first identified as a pre-defined templateIdent must be considered a userDefined templateIdent. For each userDefined templateIdent found in StoryText, a corresponding entry must be found in the userDefined Descriptions section of the MadLib file. During the substitution input phase, the user must be prompted once and only once for each unique userDefined templateField. The advantages of userDefined templateIdents or templateFields include 1. The writer of the MadLib file can specify exactly what is required of the user, for instance "A Body Part" or "A Verb ending in ing" 2. The writer can use the same userDefined templateField multiple times within the StoryText, with each instance replaced by the same user substitution. TemplateField Escape Character Sequence To handle the case where storyText contains a '@' character that is not part of a templateField, i.e., that should be considered part of the storyText itself, an escape sequence is provided to handle this condition: @@ must be replaced by a single '@' character when encountered in the StoryText. Be careful to skip over the '@' that replaces the '@@' sequence or you'll be sorry... Example A valid MadLib file's contents are shown below: Note the first three lines are comments, and must be ignored. Note that empty lines are allowed, and are ignored during 1st pass analysis, but must be printed in the final output. After Pass 1 analysis, the templateFields that should have been identified and stored are (in order as found, though not necessarily the order in which they user is prompted): @BE@ @noun@ @NOBLER@ @MIND@ @verb@ @nouns@ @nouns@ @adj@ @nouns@ @noun@ @nouns@ Also, notice that the "@@" escape sequence is encountered in Will Shakespeare's email address Finally, notice that the @end-of-story@ token is followed by a userDefined descriptions section, which provides user prompts for the three userdefined templateFields that were found, @BE@, @NOBLER@, and @MIND@. Obviously, the user should not be shown the template field identifiers, though during development, it might be useful to the developers to see them # test madlib "To be or not to be" # # To @BE@, or not to @BE@, that is the @noun@: Whether 'tis @NOBLER@ in the @MIND@ to @verb@ The @nouns@ and @nouns@ of @adj@ Fortune, Or to take @nouns@ against a @noun@ of @nouns@ wshakespeare@@theglobe.com Take from the original, Shakespeare's "Hamlet", Act 3, Scn. 1: To be, or not to be, that is the question: Whether 'tis Nobler in the mind to suffer The Slings and Arrows of outrageous Fortune, Or to take Arms against a Sea of troubles @end-of-story@ # beginning of userDefined descriptions @BE@ A risque verb, if you dare @NOBLER@ An adjective ending in -er @MIND@ part of the bod