This is a mostly copy of last years page,
so the comments are from John so far
Information from the teaching assistants
Assistant on this course is Anders Hessel.
Office: room 1436 (Floor 4 of house 1).
Profiling GCC
If you have trouble profiling GCC, try:
/it/sw/gnutools/bin/gprof tracer gmon.out
(Assuming your binary is named 'tracer', and assuming 'gmon.out' is the file with raw profiling data)
Optimizations
One common problem with optimization seems to be the use of 'inline'. To make a function inlined outside of the C file where it is defined, you need to include the entire function with keywords 'static inline' in the header file.
This is because the C compiler compiles one C file at a time, so it does not know what to inline otherwise.
First hand-in
I have a few comments on the first hand-in:
- Section 2 of the project specification list some items that MUST be included for each hand-in. Only exception for first hand-in was that no make-file was required. Specifically, change-log and distribution was missing for some of you.
- You should solve the complete assignment in your hand-in, not just selected parts. The reading and writing of PPM-files is the major part of the first hand-in. Witout it, I cannot give you much feedback - and the first assignment is all about giving you feedback.
Dictionary
The explanations of these terms are shortened versions of the definitions found in either wikipedia
or FOLDOC.
Precondition
A precondition is a fact that must always be true just prior to the execution of a function.
(From wikipedia)
Postcondition
A postcondition is a fact that must always be true just after the execution of a function.
(From wikipedia)
Side-effect
A side-effect is a property of a function that it modifies some state other than its return value. For example, a function might modify a global or "static" variable, modify one of its arguments, write data to a display or file, or read some data from other side-effecting functions.
(From wikipedia)
Previous Course Instance
Here is a brief list of common mistakes made for the first hand-in last year:
- Missing development log
- Missing dependencies between modules in external documentation; There should be a description of usage-dependencies between ADTs.
- Pre- and postconditions should be included both in external and in internal documentation.
- Error handling: do not print anything, do not exit, just return an error code. It should be up to the application code to present error messages to the user, and to take appropriate action.
- Program errors (bugs) should be detected and handled by using assert. This will help catch illegal data early, that otherwise could cause some other part of the program to crash. Use assert for example to check the domain of input arguments.
- Bitmap, color, and vector should be stack allocated. They are small, and especially for colors and vectors there would otherwise be a memory management nightmare. Since the bitmap contains some color matrix, you still need some method to free the associated memory.
- Long functions: a function should not be longer than what can be printed on one page. Too long functions can be divided into several smaller functions.
- Incorrect input should not crash your program. An incorrect file can end prematurely, or contain a word with more than 70 characters.