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).
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)
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.
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.
A precondition is a fact that must always be true just prior to the execution of a function.
A postcondition is a fact that must always be true just after the execution of a function.
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.
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.