This program will help you gain practice with branching (ifs in particular). (It might also provide you opportunities for practicing indefinite looping.)
Write a program that determines whether the room being used for a meeting is in violation of fire law regulations regarding maximum occupancy (the most people that are allowed to be in the room — if there are too many, it becomes more difficult to get out of the room in case of a fire!).
This program will need to know the capacity rating of the room (as determined by the local fire chief and the relevant governing body) as well as the number of people that have shown up to the meeting (probably determined by a waiter or sous-chef counting heads from the kitchen doorway; *grin*).
Your program must report whether the meeting is legal or not. The meeting is legal if the number of people in attendance is less than or even equal to the maximum occupancy. The meeting is illegal whenever the number of attendees is greater than the maximum allowed attendance.
In addition to this simple declaration of legality, also provide the user with a percentage of the room that is being used (based on the maximum occupancy — not area/volume). This percentage should be rounded to the nearest whole percent.
Finally, let the user know either how many people must leave the meeting before the fire regulations will be sated or how many more people are allowed to arrive before the fire regulations will be violated.
As an example, you might have the program interaction look something like (the parts in this color are typed by the user):
$ ./roomcap.out
Welcome to the Room Capacity Program!!!
How many people can this room hold? 32
How many people have arrived for the meeting? 22
You've used up almost 69% of your room's capacity!
However, I pronounce this meeting LEGAL! Proceed with the congregation!
(BTW, you have room for 10 more people...)
Thank you for using the RCP!!
Endeavor to have a tremendous day!
$
Note how the percentage here is rounded to the nearest whole percent...
This assignment is (Level 2).
As more people arrive at the meeting, those in charge must continually check that fire regulations are not being violated. Running your program over and over could get mildly annoying...*shrug*
Add (Level 1) to make your program repeat at the user's wish. (Hint: *ahem* Yes/No loop... *ahem*)
Some users have complained that when 19 of 32 allowed occupants have arrived, the program is telling them that 'almost' 59% capacity has been reached. Sounds a little whiny, but they are technically correct. 19/32 is 0.59375 which is not 'almost' 59%, but rather 'just over' 59%...
Add (Level 1) to adjust the word choice in the percentage message to be based on which way the percentage was rounded: up, down, or not at all. For example, if only 19 people had shown up [in the above example] instead of 22, the percentage would have been 59% (0.59375 rounds down). But, then the verbiage would have read almost 59% when really it is just over 59% — not almost. (Don't forget about the situation when no rounding has occurred! In that case, the percent of the room that's been used is exactly the stated percentage.)
Some users have complained (and oddly not the same ones as above) that when only one person must leave or only one more person may arrive, the program states that 1 people must leave or may arrive. Again, they are whiny but correct. (Isn't saying 1 people like saying all of a tribe, nation, or race can be there?)
Add (Level 0.5) to adjust your word choice when reporting how many people must leave or how many more people can arrive to be based on whether only one person may arrive/must leave or whether 0 or more people can stay/must leave.
The task of counting heads at these meetings and checking the fire regulations often falls to the newest member of the staff. And when the poor chap makes a simple typing mistake and hits, say, -9 instead of 9, the senior staff members constantly raz her/him about it.
Add (Level 1) to add a validation loop during the input portion of your program to ensure that the user's numbers are non-negative. This will stop the harassment of the junior staff by the more experienced staff when the report shoots out. (It won't read -14% or such like any longer. *smile*)
No matter who is entering the counts for checking fire regulations, it makes you look bad when the user enters a 0 maximum occupancy. Why? Because then you report that there is inf% of the room in use. (*chuckle* *giggle* *rofl* *guffaw*)
Add another (Level 0.5) to adjust your validation loop for the room's maximum occupancy to not allow 0, either. (A room that can hold no people isn't of much use in this program...and gives the programmer a bad reputation when the resulting calculation is displayed!)
We're not sure who, but some dingus has been entering symbols, words, and worse at numeric prompts! Unless you made the yes/no loop, this isn't too terrible. But with that option in place, your program becomes a living nightmare!
Add (Level 1.5) to adjust your validation loop(s) so that the user can't even derail your program by typing non-numeric characters at your numeric prompts.
The longer your main program becomes, the more difficult it becomes to maintain and adjust. This (and other problems) is taken care of by simply using the idea of functions and top-down design principles! By modularizing the program, we not only reduce the size and complexity of the main, but we may also eliminate bugs, be able to re-use one function for two separate tasks, and even make the whole program more readable and manageable.
Add (Level 3) to use functions to break up your program into more manageable pieces instead of having lots of repetitious code in a long, long, long main program.
If you did all above options, this lab could be worth as much as (Level 10.5).