| CMSC 106 | Project #2 - Shipping Packages | Fall 2002 |
In this project you will write a program using various conditional statements. You will be writing a program that is used by a fictitious shipping company. The input will consist of the current date, the weight and volume of the package, and the number of miles it must be shipped. The program will determine the type of shipping (air or ground), the cost, and the date of arrival.
10 17 2005 6.3 1500 782
The first line represents a date, in this case ``October 17th, 2005''. The second line is a floating point number representing the weight of the package (pounds). The third line is an integer representing the volume of the package (cubic inches). The fourth line is an integer representing the number of miles the package will be shipped.
For this project, you may assume that the user will enter valid data. In other words, you may assume that the first value in the input will be an integer between 1 and 12, that the second value will be an integer that corresponds to a valid date in the selected month, etc.
Your package will be shipped by AIR The cost will be $3.30 The package will arrive on 10/18/2005 Thank you for your business!
If the package had been sent by ground, then the first line would have ended with the word ``GROUND''. Note that the cost is displayed as a floating point value with two digits after the decimal point. The date must always be of the form mm/dd/yyyy. For example, ``April 5th, 2007'' would be displayed as ``04/05/2007''.
All enormous packages are consiered bulky.
Heavy packages that occupy more than 3000 cubic inches are considered bulky.
Medium packages that occupy more than 1200 cubic inches are considered bulky.
Light packages that occupy more than 800 cubic inches are considered bulky.
All other packages are considered non-bulky.
The cost for shipping a package by ground depends on the size and whether or not the package is bulky. Note that the distance that the package is being shipped does not figure into the ground shipping charge.
| Costs for Ground Shipping | ||||
| Enormous | Heavy | Medium | Light | |
| Non-Bulky | n/a | $1.45 | $1.00 | $0.60 |
| Bulky | $2.50 | $1.75 | $1.20 | $0.70 |
| Base cost for Air Shipping | |||
| Enormous | Heavy | Medium | Light |
| $3.25 | $2.00 | $1.50 | $0.80 |
| Costs for each 1000 Air Miles | ||||
| Enormous | Heavy | Medium | Light | |
| Non-Bulky | n/a | $5.00 | $3.50 | $2.00 |
| Bulky | $8.50 | $7.25 | $4.50 | $2.50 |
| Days in each Month | |
| January | 31 |
| February | 28* |
| March | 31 |
| April | 30 |
| May | 31 |
| June | 30 |
| July | 31 |
| August | 31 |
| September | 30 |
| October | 31 |
| November | 30 |
| December | 31 |
*Don't forget about leap years. If the year is divisible by four, then February will have 29 days. (By the way, this is really an oversimplification. The actual rules for determining when leap years occur are much more complicated.) There are other calendar adjustments that take place from time to time, which we will ignore.
cc -std1 -trapuv
on the OIT
UNIX Class Cluster. Even if you already know what they are, you may not use
any C language features other than those introduced in Chapters 1 through
5 of your textbook. Note that loops, arrays, and user-defined
functions may not be used. In addition, your program must contain only one
single return statement at its end. Using C features not in these
chapters will result in losing credit.
Your program must have a comment near the top which contains your name, login ID, student ID, your section number, your TA's name, and an original description of the action and operation of the program. Your program should be written using good programming style and formatting, as discussed in class and throughout your textbook. For this project, style is considered to consist of:
We have provided two files (primary_input and primary_output) to help
you test your
program. If your program is run using the file primary_input as the data source,
then the output should look exactly like the file primary_output. You can use
UNIX
redirection and the diff command to check your program with this sample data.
Here's how:
a.out
primary_input as the data source, and another
file for the output. We'll suppose the other file is called myoutput:
% a.out < primary_input > myoutput
primary_output file:
% diff -bwi myoutput primary_output
If your output is correct, the diff command should generate no output of any kind.
If your output is different from the primary_output file, the diff
command will show
you what lines are different.
Important: We will be testing your program with many different data sets, not
just the primary_input mentioned above. You will lose substantial credit for
each test case that your program does not handle correctly. For this reason, it is very
important that you test your program with a wide variety of input data.
You may want to skip this section at first, read the rest of the project, and come back to study it carefully when you are about to begin writing your program.
It is very important to continue to type in only a part of your program at a time and verify that it's correct, before going on. Any mistake is much easier to locate this way. The idea is that at all times you have a correct program, which may be incomplete and solve only part of the problem but at least the part you've written so far works.
In other words, do not attempt to write your program to perform all the necessary tests or produce completely correct output at first. Add code to perform only one processing step at a time and produce its output, and then add another until your program is complete.
For example, here is one way to begin developing the program one part at a time. Write the code for each of the following steps, and compile and test at each stage to make sure the correct results are printed for different inputs before going on to the next step listed.
else, the else is not placed so it's inside an
if statement. Only one statement can appear as the
subsidiary statement after an if, and only one statement
can appear after an else. If you want more than one
statement to appear in a place where one statement belongs, you
can use braces to group them into a compound statement. You may
have forgotten braces around the statements which were supposed to
be executed if the condition in the if/else was true
(the first group of subsidiary statements). Alternatively, it's
possible you made a mistake and have more elses than
ifs. You are much less likely to make this mistake when
your code is properly formatted and indented, with each
else lined up to clearly indicate which if statement
it belongs to.
If your program doesn't produce the results you think it should, the debug
printf statement is the best tool you can use. If, for instance,
you're not sure why one branch of an if/else statement is
being executed when you think the other should be, put a debug printf
statement right before the whole if statement which prints the values
of all the variables used in the condition. Maybe one of them doesn't have
the value which you think it should have at that point. On the other hand,
if you run your program and see that the variables all have correct values,
then the condition itself is probably not expressed correctly. Or perhaps
nothing prints in some case where you think something should. Try adding an
else to every if statement which doesn't already have one,
which prints a message indicating what must be true for that statement to be
printed. Also in other cases, add as many printfs as you need to
determine what is true about the data currently stored.
Make sure the debug printfs you add are descriptive in nature to
tell you any information you may need to determine what your program is
doing, such as what line in in the program is producing this output or what
the values of all relevant variables are at that point. This is much more
useful than printing something like ``I am here'' in your debug
printfs. Also, make sure the debug printfs do not
change what statements are controled by the if or the else.
Also for technical reasons not worth explaining, it is very important that
every debug printf ends with the newline character '\n'.
Although these debug printfs will make your output look incorrect,
they will help you develop your program correctly.
Make sure that all debug printfs are removed before you submit your
source code file for grading. After removing them, before submitting your
source file, make sure that you have compiled, run and tested your project
again to be sure you did not accidentally change it when you were removing
those lines.
If you can't find the problem after trying to debug your program using these techniques, bring printouts of your program and any compiler errors or execution results to office hours. To help us find the mistake as quickly as possible, be prepared to demonstrate and explain how you have tested your program, and what results you got.
It is very important to test your program against all different possibilities of input data, not just those provided by us. Doing this correctly involves thinking of what other input values are possible based on the project description, and what results the program should produce in those cases.
As an example, say you had to write a program which reads three integers
into variables a, b, and c, and prints the name of the
variable which had the largest value. Imagine that you wrote the following
program:
#include <stdio.h>
main() {
int a, b, c;
scanf("%d%d%d", &a, &b, &c);
if (a <= b) {
printf("b");
if (b <= c)
printf("c");
} else printf("a");
printf("\n");
return 0;
}
Try typing, compiling, and executing this program.
If you run the program and enter 2 6 4 it prints ``b'', which is correct.
If you run it and enter 6 4 2 it prints ``a'', which is correct.
You might assume the program works since you ran it twice with different input values, but it is not correct.
Try entering 4 2 6 and it prints ``a'', which is wrong.
Try entering 2 4 6 and it prints ``bc'', which is also wrong.
There are other possibilities of input values which cause incorrect results as well.
The conclusion is that it is always necessary to think of all the different possible combinations and possibilities of input values which might appear in a program's input, and test it so you are certain it works correctly in all cases, not just for one or two different inputs.
If you are curious, one correct program to perform this task is as follows. The program could also be written using the logical operators.
#include <stdio.h>
main() {
int a, b, c;
scanf("%d%d%d", &a, &b, &c);
if (a <= b)
if (b <= c)
printf("c");
else printf("b");
else
if (a <= c)
printf("c");
else printf("a");
printf("\n");
return 0;
}
One development policy which is extremely important is to use proper
indentation from the beginning. Many students type in their programs any
way at all, with poor or no indentation, figuring once their project works
correctly they will clean it up before submitting it. This is a very bad
idea, because it is much harder to find certain errors in a program with
poor indentation, and it's much easier to make these types of mistakes. You
are much more likely to have problems such as mismatched braces, or
misplacing an else, or misunderstanding which statements are
subsidiary to which if statements if your code is improperly
formatted or indented, or the braces are incorrectly placed. In the Q+A
sections your textbook shows several popular styles of indentation. It
doesn't matter which you use, as long as your code is clear and your
indentation is consistent, subsidiary statements are all indented, and
statements at the same level are all indented the same way. If you come to
office hours for help with a program which has missing or very poor
indentation, you will be asked to correct and reformat your program before
we are able to help you further with it.
Any evidence of unauthorized use of computer accounts or cooperation on projects will be submitted to the Student Honor Council, which could result in an XF for the course, suspension, or expulsion from the University. Projects are to be written INDIVIDUALLY. For academic honesty purposes, projects are to be considered comparable to a take-home exam. Any cooperation or exchange of ideas which would be prohibited on an exam is also prohibited on a project assignment, and WILL BE REPORTED to the Honor Council.
VIOLATIONS OF ACADEMIC HONESTY INCLUDE:
|
IT IS THE RESPONSIBILITY, UNDER THE UNIVERSITY HONOR POLICY, OF ANY STUDENT WHO LEARNS OF AN INCIDENT OF ACADEMIC DISHONESTY TO REPORT IT TO THEIR INSTRUCTOR.
Your project must be electronically submitted by the date above, before 11:00pm, to avoid losing credit as indicated on the syllabus. No projects more than two days late will be accepted for credit without prior permission or a valid medical excuse, as described on your syllabus. Only the project which you electronically submit, according to the procedures provided, can be graded; it is your responsibility to test your program and verify that it works properly before submitting. Lost passwords or other system problems do not constitute valid justifications for late projects, so do not put off working on your program or wait to submit it at the last minute!
Turn in your assignment using the ``submit'' program as before, except using ``2'' for the project number. You are to submit only the .c file containing your source code, not the executable version of your program! If your program is in a file named ``p2.c'', submit would be run as shown.
Before you submit your project, you must exactly follow the specific submission checklist in the ``Testing projects before submitting'' handout separately posted by your instructor!