Instructor: | Karl Abrahamson |
Office: | Austin 233 |
Office hours: | MW 3:30-5:00, TTh 10:00-11:00 |
Phone: | 328-1879 |
Email: | karl@cs.ecu.edu |
Text: | Data Abstraction and Problem Solving with C++: Walls and Mirrors by Frank Carrano |
Notes: | Computer Science 3510 Notes |
Web page: | www.cs.ecu.edu/~karl/3510/fall99/ |
In this course, we will study advanced techniques in computer programming, using the C++ programming language. Topics to be studied include the following.
You must expect to do a significant amount of work outside of class. If you do not have time to devote to this class, drop the class now. Students who do not put in the work can expect to fail the class.
This is a programming course, and students are expected to complete programming exercises. You may discuss your ideas with other students, but your programs must be your own work. Copying of programs will be considered plagiarism.
Grading will tentatively be as follows. Programming assignments will count 35% of your grade. There will be two midterm exams counting 18% each and a final exam counting 29%. Tentative cutoffs are 90% for an A, 80% for a B, 70% for a C and 60% for a D. Those cutoffs might be adjusted to account for overall class performance and the difficulty of the assignments and questions, but they will not be raised.
Important proviso. It is not possible to learn the material of this course effectively without actually ``getting your hands dirty'' and doing the programming. Accordingly,
in order to pass this course, you must receive at least a 60% grade in the programming assignments and at least a 60% grade in the exams.This outweighs the score computed by adding grades together.
-Wall -Wshadow -Wpointer-arithWarning flag -Wall causes all common warnings to be given. Warnings about use of uninitialized variables will be given, but only if option -Wall is used in conjunction with flag -O, which causes the compiler to optimize code. (Uninitialized variables are detected during dataflow analysis, which is only performed as part of optimization.) Optimized code is more difficult to debug than unoptimized code. Your best bet is to compile with -O to get the warnings, but to recompile without -O before you run the debugger.
Programs will be graded according to the following broad criteria.
First, the program must compile without fatal errors.
A program that does not compile automatically receives a score of 0, regardless of how close to correct it might be.
To receive an A (90-100), a program should work on all of the test cases that I use. (You will not be given my test cases.) It should be well indented and well commented. Comments should be clear, correct and complete. It should be broken into fairly short, well-thought-out functions. Variable and function names should be sensible. It should follow all guidelines and requirements that have been set for the program. It should compile without warnings.
To receive a B (80-89), a program should work on typical test cases, though it might fail on more esoteric cases. It should be well commented and well indented, though minor problems might be present. It should be broken into fairly short, well-thought-out functions. It should mostly follow the guidelines and requirements that have been set for the program. The compiler should not report serious warnings that reflect mistakes in the program.
To receive a C, a program should work on at least some test cases. It must be reasonably commented and indented, though some comments might be misleading or incorrect. It should be broken into reasonable functions. It should make some attempt to follow the guidelines and requirements that have been set out for the program.
To receive a D, a program might not work correctly on any test cases, but the basics of the design must be present. The program should be acceptably well indented. I will not read a program that is very poorly indented. It should make some attempt to follow the guidelines and requirements that have been set out for the program.
You will be given two opportunities to do each program. After the first attempt, you will receive feedback, and can modify your program. If you miss the deadline for the first attempt, you will have only the second attempt.
Late submissions for the first deadline will not be accepted. Late submissions for the second deadline will be accepted with a 5 point penalty (out of 100) for each 24 hours that the program is late. Programs will not be accepted after the last day of classes unless you are informed otherwise.
I will provide some feedback on anything that is turned in as a first attempt. However, I do not guarantee to find all errors. You should certainly fix all errors that I point out, but that is not necessarily adequate. You are expected to fix those and any additional errors that might exist before turning in the second attempt.
If you turn in a high quality first attempt, then you can expect that the errors that I point out will be fairly complete, and your second attempt will consist mainly of fine-tuning. If you turn in a low quality first attempt, then you can expect that the feedback that I give will be quite incomplete, and you will have major work to do for the second attempt. If you do not turn in the first attempt, then you will have no feedback at all before turning in your second attempt.
Programs should be submitted by email to karl3510@cs.ecu.edu. Note the email address! All source files that are part of the program, including header files, should be attached to the email message. The body of the message should be empty. The subject of the message should have the following form.
3510 Assn k pass n your namewhere k is the assignment number, n is the pass number (1 or 2) and your name is your name. Do not attach executable files or makefiles. Attach the files under the exact names that you have used. Do not, for example, change the name to all upper case. Never send your program as a document for a text-processing system, such as Microsoft Word or Html. Such documents are unacceptable. Only send programs as text. If you are unsure how your program is being sent, send it to yourself to find out.
Include your name in a comment at the top of each file.
You are encouraged to ask questions about your programs when you are stumped, especially if you come up against a difficulty with the language. Send questions early, to leave yourself time to make progress after receiving an answer. Send questions to karl@cs.ecu.edu, not to karl3510@cs.ecu.edu.
If you have questions concerning programs, do not use a subject line that makes the inquiry look like a submission. Use a subject that begins
Question about ...so that I will not confuse your question with a submission sent to the wrong address. To ask a question about a program, attach any files that are relevant to your question.