This lab will help you practice with classes and libraries.
In olden times — even before I was born! — shoppers at a grocery store would keep track of their purchases with a simple hand-held counter. A click to any of four buttons would spin the gears inside so that the digit associated with that button would increment. Typically the four digits were viewed as tens, ones, tenths, and hundredths to line up with monetary needs. I recall seeing one of these at my grand-parents' house once: it was shiny red plastic with four holes through which you could view the digits and there was a $ stamped in front of the first window and a . stamped between the first and last pair of windows. (It was a way to have a small child waste several hours clicking inanely at the little buttons and thus not annoying you for this or that...*grin*)
Design and code a class to represent this 'little red counter' concept. Your Counter should be able to hold any valid 4-digit number from 0 to 9999. When the 'hundredths' button is clicked for a Counter object that represents 9999, it should wrap to 0 and remember that it has 'overflowed'.
Methods should be provided for:
construction from nothing (setting the counter's value to 0), a certain starting value (which must be in [0..9999] or we'll have failed), or another Counter object
access of the entire Counter, access of the 'dollars', and access for the 'cents' should be provided for the programmer's convenience
mutation at an individual digit level (like the original device with its buttons) as well as to change the counter to an entirely new value (within [0..9999], as during construction)
Also allow the programmer using the class to detect an overflow condition and to reset an overflow condition. (They don't need to be able to set such a state, however.) In fact, you can treat this like cin's fail flag — don't tell 'em 'til they ask. (Programmers call this a polled or asynchronous state — as opposed to an interrupt/synchronous setup.)
But why restrict ourselves to mimicking a tired old plastic device? Let's make it more general by allowing the programmer using the class to change the maximum for the Counter. This can be done as a number of digits or as a specific value — at your discretion. (The last two [base ten] digits are always to be considered the 'cents'.)
Provide the ability to display the Counter's amount in either a monetary fashion (1234 displays as $12.34; or 509 displays as $5.09) or a raw fashion (1234 displays as 1234; or 509 displays as 0509). (As above, the last two [base ten] digits are always considered the 'cents' in the monetary display.)
You do not need to provide any means of direct input from the user. The button interface of the original device is a bit complicated for us to mimic within a generic Counter class. Allow for the application to provide such an interface — or whatever they wish — instead of us.
Place your counter ADT in a library.
To make sure the Counter works correctly, write a driver (test application). Here you can provide any sort of interface you like, but a simple one would be A — 10's, S — 1's, D — 0.1's, and F — 0.01's. (Note that ASDF is right there on the keyboard together... And if you don't believe in the power of ASDF, may I suggest you check out the cul...er...organization. And, no, the .org and the .net are not the same; although the .org may be useful...somehow...)
How can you separate the digits of your integer member for returning portions of it from the different accessors?
How can you make sure you get appropriate decimal places when displaying 'real' numbers? How can you make sure you get the right number of digits when you are displaying a '4-digit' integer?
When you detect overflow, do you continue incrementing the Counter?
What data type does your Overflow method return?
Normally, our output methods wouldn't print anything besides the Counter's value (not even an endl!). Why does this one (note the leading 0 for 509 and the $ during a monetary-style display)?
Could you make it a little more configurable so the programmer could specify different monetary formats/units? What new data members would that require? What other accessors, mutators, and construction patterns would be necessary?
This assignment is (Level 3).
Add (Level 2) to properly apply inline'ing and const-ness to all of your class methods. (This includes proper use of initializer lists on constructors!)
Should any of your methods be inline'd for speed? Which ones will you inline? How does one do this for a class method?
If you end up inline'ing all of your methods, do you still need an implementation file for your library? Why/Why not?
Do the accessors, output, or math operation methods alter the calling object in any way? How do you specify such a situation to the compiler so it can better handle/enforce your decision?
What needs to be in your constructor initializer lists? Is there a certain order to the list? Does it go on the prototype or the definition?
Add (Level 2) to present a menu for the user to set-up options (when they enter the 'option menu' command — perhaps p could be the significant mnemonic letter here?). Options you must allow them to change are:
the keys used for each counter button
whether to automatically report overflow
(if not, you should only print an overflow message when they enter the
overflow-request key — also a configurable key)
the maximum of the counter
If they hit the option command by accident, don't make them change an option or set it to what it already is. Give them a graceful way to return to normal program control. (Perhaps a 'never-mind' type of option?)
Note: The first two options control your driver application and the last one actually changes the behavior of the counter class object being tested.
Add (Level 1) to display the default/current values of options in the menu choices. For instance:
Options Menu
1) set Button Keys (10's-a,1's-s,0.1's-d,0.01's-f,overflow-o,options-p)
2) always Display Overflow? (yes)
3) counter Maximum (9999)
4) Nevermind
Choice:
After they've chosen an option (other than 4/N/n), take note of their desired changes and then return to normal program control.
(Thoughtful suggestion: The 1/B/b/K/k option might make a natural sub-menu...*shrug*)
Add (Level 1.5) to have menu options present the default/current choice and leave the option unchanged if the user simply hits Enter without giving you new information. (Hint: Keep your input buffer clean at all times to make an empty Enter-y easier to detect...)
If you did all above options, this lab could be worth as much as (Level 9.5).