Frequently Asked Questions

When you have a variable x and you want a pointer to it, use &x.

When you are declaring a variable p, and you want that variable to be a pointer, use *p.

    int *pInt;   /* declares pointer pInt to variable of type int */
    int *pChar;  /* declares pointer pChar to variable of type char */

Generally, &x will occur in argument-lists in invocations and *p will appear in assignment statements and declarations of parameters in functions.

 
    kennedy% gcc -ansi -c date.c
    date.c: In function `f':
    date.c:49: warning: return makes integer from pointer without a cast

 
    char f(char month[100]){
      ... other statements ...
      return (month);
    }

The second form would follow the examples in the stringExtras module. But, in either case, don't try to invoke the function on the right-hand-side of an assignment statement. Simply use the function as a command, by itself, in the same way that you have been using the strcpy and strcat functions.

Example invocations:

 
    char x[100];
     ...
    strcpy(x, "some stuff");
    strcat(x, " ... other stuff ...");
    f(x);
     ...

    gcc -ansi -c stringExtras.c
    gcc -ansi -c yourProgram.c
    gcc -lm yourProgram.o stringExtras.o 
    a.out

You only need to compile the stringExtras module once (gcc -ansi -c stringExtras.c), no matter how many times you recompile your program. But, you'll need to to the link step (gcc -lm yourProg...) every time you recompile your program.

The explanation under the "compile and run" link in the style guide for this project went to the wrong place. That's been fixed now. Also, I've updated the explanation in the Project 9 write-up on the web of the string functions (from the intrinsic string module and from the supplied module stringExtras) to make it more clear how to use the functions from the stringExtras module.

Tom Wolfe, in his book on astronauts (The Right Stuff), points out a similar conceit in fighter pilots. Many of the early jet fighters had landing speeds that were too high for safe operation. There were lots of crashes, and the pilots who hadn't (yet) crashed comforted themselves with the belief that it wouldn't happen to them if they were just careful. Turns out, the luck element was a little higher than they allowed themselves to think.

The time of people using the software is even more important, of course, since (one hopes) there will be more of them than were on the team that developed the software. But, programmers almost never know in advance which details of their codes need to be efficient. After they've gotten the code working properly, they can use tools such as time and memory profilers to find out which components to optimize.

This course focuses on what programmers need to do first. Subsequent courses will address efficiency issues.

If there is a role for debuggers, it is in verifying hypotheses, formed during code inspection, about the defects that trigger observed symptoms of errors. Debuggers cannot effectively take the place of code inspection, regardless of your experience.

Arrays are an important aspect of C and will be covered in this course, along with appropriate examples of their use. Project 9 provides no such examples.

I require that programs submitted in completion of Project 9 remain independent of the particular implementation of the string abstraction that C has chosen. To do this, you must use string functions to analyze strings, and you must avoid the use of array operations, such as subscripting.

Arrays are usually defined as sequences whose lengths are fixed at the time of declaration. This makes the array abstraction a poor choice for implementing strings, or for any type of sequence demanding operations such as concatenation, insertion, and deletion that lead to flux in the length dimension over the course of the computation.

The designers of C chose to represent strings as arrays almost three decades ago. Probably, they made this choice because the array representation uses memory economically. They made their decision at a time when fast-access memory, even on the most advanced computers, ran at a few megahertz and when that memory, even on the cheapest systems, cost tens of thousands of dollars per megabyte. (Actually, you couldn't really get memory by the megabyte -- it came by the kilobyte at that time.)

So, it was crucial in those days to use memory with great care. Software people spent much of their time (well over half, I believe), figuring out how to conserve it in their programs, or getting around the problems caused by their attempts to conserve it. Unfortunately, these habits persist to the present day, when they are rarely justified on an economic basis. When you take your first professional position in computer science, they will be justified even less often. For this reason, you will be better rewarded for learning well the principles of abstraction on which good software is constructed than for fiddling around with memory conservation excersises.

There are thousands of people in the programming business whose level of understanding of the principles of computer science does not encompass these principles. They hack out defect-ridden, unmaintainable software with alacrity.

The university is attempting to educate a new generation of computer scientists who appreciate the difficulty and importance of producing well-organized software grounded those few principles that have come to light in the short history of the discipline. I hope that you will be a literate and contributing member of that new generation.

   const char s[] = "some string";
   char t[100];
   strcpy(t, s); /* at this point, t[] is "some string" */
   strcap(t);    /* at this point, t[] is "SOME STRING" */

But, there is no reason to compute e in this problem. It doesn't matter what log base you use, as long as you use the same base to compute constants that you use in the model that estimates time (after you plug in the constants).

To fix your PC file so it will work on Unix, get into Hugs and load the removeBS.hs program (from Supplied Software on the web site). The enter Hugs command

Now you should be able to run the C compiler against yourProgram.c

Software designers should transfer from people to computers as much as possible of the work required to carry out the task at hand. Computers should serve people, not the other way around. The job of the software designer is to make computers into effective helpers, or even obsequious servants if that pleases the people using the software. This is especially important if the people using the software have the misfortune to be stupid, which most people aren't, of course. Software designers certainly must not allege stupidity in other people as a smokescreen to hide laziness in the software development process.

You might ask why the picture was constructed this way in the first place: turns out its easier to build it upside down, less complicated counting.

THIS:

> variableOne = ...
> functionTwo xs = ...

> variableOne = ...
>functionTwo xs = ...

LIKE THIS:

> displayDictionSignature textString =
>   second line starts here
>   third line starts here (or could be indented further)
>   fourth line starts here (could be indented more or
>     less than third line, but must be indented further
>     than first line of definition)
> next definition starts at same indentation as other first-lines ...

The reason for this is that Haskell uses indentation level to mark the beginning and end of definitions. Older languages use special markings for this purpose, such as matching brackets ({...} or begin...end) or separators (usually semicolons). But, good programmers always use indentation to visually delineate program segments. Bracket and separator marks are redundant when programs are properly indented. So, Haskell avoids the visual clutter of bracket and separator marks by relying solely on indentation.

Now, about those semicolons ...
Haskell has an alternate source form that uses semicolons as separators. This form is more compact, so Hugs translates what you write into the compact form (with semicolons) before it interprets your program. When your script is indented improperly, extra semicolons get inserted in places where they unexpected. You should interpret the "unexpected semicolon" error message as an indication that your indentation is messed up at some point.