CSE 332S: Object Oriented Software Design Laboratory

Fall 2008: Lab 1

Purpose

Preparation

1. Make a directory for this lab, where all of your source files will live.
2. Make sure you understand the basic data types in C and and how arrays work.
3. Review the information about the preprocessor, especially the use of #include, #ifdef, and #ifndef.

Assignment

1. Create a new file, lab1.c, with a main function in it. Make sure it compiles.
2. In main(), declare an array of 1000 doubles.
3. Write a function that takes an array as a parameter, and assigns random values to each of the elements. This function should not assume that the size of the array is 1000 (ie, pass in the array size as a parameter to the function). Hint: Arrays can be treated just like pointers, so you can pass this array as a double *. This function should live in a separate file, with it's own header file. You should use the C function drand48() to generate random numbers.
4. Write a function to sort the array into ascending order. An acceptable sorting algorithm is bubblesort, but you are free to use whatever approach you like. This function should also include code that checks to make sure that the array is properly sorted before returning. The checking code should be contained inside preprocessor directives, so that it is only compiled if NDEBUG is not defined. If NDEBUG is defined, the check code should not be compiled. Again, this function should live in it's own file, and should not assume the size of the array.
5. Write a function to print out the array, one value on each line, to three decimal places, using printf. Once again, the function should not assume the size of the array is 1000.
6. Write a function to read values into the array from the keyboard. Since the syntax for this is a bit annoying, here's an example:

   double a[10];
int i;
for(i = 0; i < 10; ++i)
  scanf("%lf", &(a[i]));


   Since it's not practical to test this with a 1000-element array, you should test that it does the right thing with a smaller array. You can also use this to test your array sorting routine.
7. Implement the following in your main() function.
   1. Read in 1000 doubles from the keyboard.
   2. Sort them into ascending order.
   3. Print out the sorted list.
8. Add a command-line switch to your program. If you invoke your program like this:

   lab0 --random

   it will generate 1000 random numbers, rather than reading them from the keyboard, and then sort them. Running your code without the --random flag will read the numbers from the keyboard.

Grading

1. Deviations from the design above, such as all of the code in a single source file, or not using function calls.
2. Not compiling. If your code does not compile, then you will get no points for this lab.
3. No warnings or errors in the compile. Your code should not generate any warning messages when compiled with the -Wall flag.

What to Hand In

Thoughts

1. There are no objects in this lab. Your array should be declared locally in main() and passed to the functions you write.
2. You are implementing a Unix filter program here. Unix lets you redirect the contents of files, as if they were typed at the keyboard. For example, create a file with 1000 doubles in it, called infile. Running the following:

   lab1 < infile > outfile

   will take the contents of this file, and send them to the program, and then take the output of the program, and send it to the file outfile.
3. When you're looking at the command-line parameters to your code, you need to use the strcmp() function, not a direct comparison with ==.
4. You should have separate files for
   1. Input and output functions.
   2. Sorting functions.
   3. Array-filling functions.
5. When you compile your code, turn on all of the warnings (-Wall). Don't submit code that still causes warnings.
6. An example of the final program can be grabbed here. If it doesn't run, type the following incantation:

   chmod u+x lab1

   and try again.
7. We've not asked to you test your code formally for this assignment. However, you should come up with some test cases and try them, to make sure things work as expected. We'll talk more about formal testing in future lectures.