CS 127 Final Project, Spring 1997

What to hand in

• A description of your program and its features.
• A description of your program's command-line syntax.
• A description and justification of the main data structures your program uses.
• A discussion of the current status of your program, what works and what doesn't, etc.
• Your program's source code.

Grading Criteria

• Successful compilation. If your program doesn't compile, I won't grade it.
• Correctness. Your program needs to do the job it's intended to do.
• Design. I will look for well-considered choices of data structures and functions, their return values, and their parameters. In the description of your project, you should explain your reasons for making the choices you made.
• Style. I want to see good indentation, descriptive variable and function names, well-placed comments, consistent loop structure, and so on. Ideally, your code will be a pleasure to read.
• Documentation. Your description of your project and the comments in your source code are important parts of your project. I want to be able to understand your project fairly well before diving into the code.
• Performance. I will not run precise time tests, but I will frown on profilers and style enforcers that take ten minutes to process a short C program.

Project Option #1: C Profiler

Profilers are most frequently used to help programmers improve their programs' performance. By first finding out what portions of your code get executed most frequently and for the longest total time, you can concentrate your fine-tuning efforts where they will have the greatest effect. It also turns out that profilers can help in tracking down tricky bugs. You can find an interesting discussion of profilers in More Programming Pearls, Confessions of a Coder, by Jon Bentley, Addison-Wesley 1988.

For this project, your job is to write a program that will take C source code as input, and produce C source code as output. The output source, when compiled and run, will perform its expected task, but will also dump profiling information to a file.

Your profiler should report the number of times each of your functions (including main()) gets called, and the total time consumed by each function.

If you get your timing and function-call-counting done, you might try to implement line-count profiling.

You could also modify your timing reports to take into account the fact that functions call other functions. For example, suppose main() calls bigfunction(), which in turn calls littlefunction(), and none of them calls any other functions. If the entire program takes 2 seconds to run and bigfunction() takes 1.5 seconds to run, and littlefunction() takes .2 seconds to run, you could report:

main:  2 s
bigfunction: 1.5 s
littlefunction: .2 s

main:  .5 s
bigfunction: 1.3 s
littlefunction: .2 s

Project Option #2: C Style Enforcer

#include


void main   (void){
int         i;
for(i=0;i<10;i++) printf("Hello\n");}

#include     

void main( void )
{
    int     i;

    for( i=0; i < 10; i++ )
        printf( "Hello\n" );
}

Once you have indentation and bracing working well, some other style elements you could work on include spacing within for, while, and if statements, spacing in parameter lists in function headers and function calls, consistent spacing in assignment and arithmetic statements, blank lines placed after local variable declarations, etc.

If you have time and inclination, you could have your program offer the user multiple styles. For example, the bracing convention I use:

    if( this == that )
    {
        dosomething();
    }

    if( this == that ){
        dosomething();
    }