CSCI 3342 Submission 04
Gathering Odds and Evens

Overview

This week's submission provides an opportunity to put your knowledge of the STL to work, and to write some code that must compile and link with an instructor-provided, previously-compiled main program driver to form the final executable.

Your job will be to implement the functions whose interfaces have been given in the functions.h specification file, and you will have an opportunity to use the STL in various ways in the development of these functions. All of the functions you write must be placed in a file called functions.cpp, which will then be separately complied and linked with the instructor-supplied driver file gather_odds_evens.o to produce your final executable file gather_odds_evens.

Steps to Perform

1. Copy the demo executable file and run it, first without any command-line parameters to see the opening screen, followed by a single screen of program description and usage information. Note that this time around there is no corresponding TextItems file to accompany the executable, so the second information screen is being produced in a different way.
2. Study the program description screen until you understand what the input and output of the program are supposed to be.
3. Run the program a few more times, with different values of the single command-line parameter input value to verify that the program behaves as advertised, and to understand the required format of the output. Note that the program does not perform any error-checking, so if there is a command-line input when the program runs, the program assumes it to be a valid non-negative integer, and is therefore not responsible for what happens if that is not the case.
4. Now study the supplied specification file (the functions.h file) to see what functions you have to write. It contains a prototype for each of the required functions, along with doxygen-style documentation. We have already discussed the doxygen documentation that you see in this file and noted that it is very similar to the javadoc documentation that you are familiar with from working with Java. So, as you know, you can document your C++ code in much the same way you can document your Java code, and also produce a similar HTML version of that documentation. But, also as you know, we are not requiring you to fully document your code using this kind of doxygen-style documentation, but it should be helpful for you to see it being used here in context.
5. Next, write pseudocode for these functions, and hence for a solution to the problem. Revise your pseudocode until you are convinced that its implementation will do the job. [See below for explicit instructions on how to write the function that displays the program information screen output.]
6. Then translate your pseudocode into C++, link it with the supplied driver to build an executable, and continue testing until you are convinced that everything works correctly. [See below for some hints on this process.]
7. Make sure your source code is identified, formatted and documented properly, according to our current rules and guidelines. Finally, submit the required files by copying them to the appropriate subdirectory in your uxx account.

Additional Notes, Requirements, Specifications and/or Hints (if any)

1. Your ID information that gets displayed on the opening screen must be made available to the supplied driver by the following line at the beginning of your functions.cpp file

   extern const string MY_ID_INFO = "\t\tLastname:Firstname:A00123456:u??";
   

   which, of course, contains your information, and not the generic information shown.
2. Note the following important requirements:
   When implementing the DisplayProgramInfo() function, you must have just two C++ statements in the function body: one cout statement to output a C++ raw string containing the entire content of the program information screen except for the pause at the end, and a second statement that calls the Pause() function to produce that pause at the bottom of the screen.

In your GatherOddsInDequeEvensInList() function you are not permitted to use any loops, which means that the moving around of values must be accomplished solely by appropriate STL algorithms and/or container methods.

Hint: STL features that you may find useful include the algorithms copy(), copy_if(), sort() and unique(), the functional object greater<>() from the <functional> header, and the output iterator ostream_iterator<>() from the <iterator> header. Appropriate use of these STL features is, of course, how you avoid the use of any loops in the function mentioned above.

3. There are at least two distinct ways to proceed when you are writing and testing your code:
   • First, you may wish to create and use your own simple test driver that you will discard once you have successfully linked to the supplied driver.
   • Second, and you may find this simpler, you may wish to use the supplied driver itself as your test driver. Of course, the supplied driver expects all of the required functions to be present when it links, so if you go this route, whenever you link you will need to make sure that any function you have not yet implemented has at least a "dummy" body so that it will at least compile and link, though it will not do anything with just a "placeholder" body.
4. You will find it helpful to use the supplied build.sh script to build your executable for testing during development, and eventually for building the the final version of the executable for submission. And once again you will also need a testing script to test each iteration of the executable as you develop the program, and this testing script is also one of the files to be submitted.