Topical Information

This lab will help you practice with strings as arguments to functions.

Program Idea

You've heard that a lot of your functions (especially input functions) will be pretty similar except for the messages with which you'll prompt or that you'll print in response to errors. Since these messages are simply string data, you think maybe you should just make them string arguments to the functions.

Thought Provoking Questions (I)

1. How do you pass a string to a function? Should it be a value argument or a reference argument? (Hint: How big is a string? Is it something that's always small? Or is it something potentially large that we might not want to make a copy of?)
2. Since you are passing these strings to be printed/displayed -- not modified -- should they be changed within the function? How can you ensure that this won't happen -- even by accident?
3. Could the caller pass literal strings ("like this one") to your function as the actual argument? Or do they have to declare a string variable/constant and pass that in? (Does your answer depend on the previous question?)

Watch...

.

.

.

out...

.

.

.

below!!!!!

Program Information

Write functions for inputting a user's answers to:

• yes/no questions
• prompts for decimal values with a specified lower bound (>= 0 for instance)
• prompts for decimal values with a specified upper bound (<= 100 for instance)
• prompts for decimal values within a specified range ([0..100] for instance)

(Note: that's four functions -- not one.)

Let the caller specify the prompts for all functions. Allow the caller to specify the error message for at least the bounded decimal functions.

None of the functions should return a value to the caller until the user has entered an appropriate value! (This is a large part of their utility/re-usability.)

Place these in a library and write a simple test program (aka driver) to show that each works as desired.

Thought Provoking Questions (II)

1. What type of value does your yes/no function return? Is it a char, a string, or could/should you be more compact?
2. Could you overload the bounded-entry functions for other types besides the decimal type you chose? Would it be necessary? Why/Why not?

3. Is overloading useful -- just amongst these four functions? (Hint: How could the compiler tell if the programmer using your library were calling the ≤-bounding function or the ≥-bounding function? ...or would it really even matter..?)

   (You kinda recall something like this:

       enum WhichEnd { Left = 1, Right, Both };
   

   from the notes/examples...hmm...)

4. Could you provide default values for the prompts and/or error messages? Should you?

This assignment is (Level 4).

Options

• Add (Level 1.5) to only write three functions instead of four. (Hint: See the original TPQ about overloading amongst the original four functions above...)

  But, of course, you'll probably want to add nice little helper functions to explicitly mimic all of the original four functions' behaviors...don't want to incite riots when the new version of your library has different call patterns than the old with no warning! That will actually bring the total number of functions in your library up to five.

  More Thought Provoking Questions

  1. Are the helper functions going to be large, long, involved functions or simple, short, quick ones? How can you let the compiler know that this might be worth exploiting?
  2. Can there be just two functions plus helpers instead of three? Why/Why not? (Hint: See the original TPQ about overloading amongst the original four functions above...)

• Add (Level 3) to add a function which limits the user's answer to a question to a certain set (aka list) of decimal values. This would mimic the yes/no function, but in the numeric world. *grin*

  In fact, it seems so much like a generalized yes/no, that I'll let you add another (Level 1) to overload this function for sets of character and integer values. (You can even add an extra (Level 0.5) to re-write your yes/no function to merely use the character-set version of this.)

  More Thought Provoking Questions

  1. When testing decimal type values for equality, the compiler isn't terribly happy, is it? How did we fix such comparisons? (Hmm...I suppose if it were close enough to the desired value...high or low, really...hmm...)
  2. How can you pass the set of values to the function? (Hmm...a group of like-typed values...all collected together...hmm...)
  3. Would a function like those of the string::find*() family be of use?
  4. If you were adding the integer overloading, would you have to overload one or two integer versions? Couldn't you just make the limiting vector of base-type long? (Hint: Is there a physical difference between 'vector<short>' and 'vector<long>'?
  5. Also, with respect to the character overloading, does it matter if the limiting set of characters is stored in a string or a simple vector?
  6. Again, with respect to rewriting the yes/no function, would it now be a large, long, involved function or a simple, short, quick one? How can you let the compiler know that this might be worth exploiting?

• Add (Level 2) to use your new library in another version of the payroll lab. (Little TPQ: Would this be even better if you did the last option about a limiting set of values [*ahem* characters *cough*], too?)

  (Be careful and don't destroy your original lab!!! ...you may want it someday. *grin* *cackle*)

• Add (Level 1.5) to add optional failure checking to the bounded(/set-limited) decimal (et.al.) functions.

Total Level Possible

If you did all above options, this lab could be worth as much as (Level 13).