Syllabus
CSCI 3510
Data Structures
Spring 2004

Class meeting TTh 6:30pm - 7:45pm Austin 306
Instructor Karl Abrahamson
Office Science and Technology C-113
Office hours TTh 9:30am-11:00am, TTh 5:30pm-6:30pm
Phone 328-9689
Email karl@cs.ecu.edu
Course web page www.cs.ecu.edu/~karl/3510/spr04/
My web page www.cs.ecu.edu/~karl/
Text Data Abstraction and Problem Solving with C++: Walls and Mirrors (third edition) by Carrano and Prichard


Prerequisites

The official prerequisite for this course is CSCI 2610. MATH/CSCI 2427 is a prerequisite or corequisite. You should have written programs in C or C++, and be a proficient programmer. If you are familiar with another programming language, you must expect to spend quite a bit of effort to learn C++.

If you received a grade of less than C in CSCI 2610, do not take this course without consulting me. You are better off retaking CSCI 2610.


Outline

In this course, we will study advanced techniques in computer programming, using the C++ programming language. Topics to be studied include the following.

  1. Dynamic memory allocation. Language features for allocating and deallocating memory on-the-fly will be studied.

  2. Concrete data structures. This is concerned with how to represent and work with data in the computer, especially using dynamic memory allocation. We will study a variety of data structures.

  3. Algorithms and problem solving. Generally, concrete data structures have associated algorithms. We will study a few algorithms and techniques for manipulating data.

  4. Abstract data types. This is concerned with how programs should be organized to make working with concrete data structures manageable.

  5. Elementary Concepts of Object-oriented Programming. Object-oriented programming can be used to implement and extend the concept of abstract data types.

  6. Correctness. You need to have some way to convince yourself that your program is correct. We will discuss informal methods.

  7. C++. We will cover the features of the C++ language that are needed.


Attendance policy

You are expected to attend class. You are responsible for announcements and assignments given in class. If you miss a class, it is up to you to obtain notes and any other information that was provided in the class. Excuses that you did not know about something because you did not come to class and did not obtain the information will not count for anything at all.

Those who do not attend class can count on doing poorly in this course. If you choose not to attend class, then you must live with the consequences of that decision, however bad they are.

No incompletes will be issued in this course except for extraordinary circumstances, and even then only if you are nearly done already, and have done work of acceptable quality so that it is realistic that you can pass the course. In particular, no incompletes will be given due to a failure to complete the assignments because of conflicts with other activities of any kind. By registering for this course, you are commiting yourself to set aside the required amount of time to complete the assignments.


Grading

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   33%
Six 30 minute quizzes   6% each
Comprehensive final exam   24%
Attendance   7%

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.

Grading of programs.

I will compile and run programs using the g++ compiler. I will use the following warning flags when compiling programs:

-Wall -Wshadow -Wpointer-arith -O
Warning flag -Wall requests warnings about use of uninitialized variables, but you only actually get those warnings if you also include 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, if you need 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.

The program must be acceptably well indented. I need to be able to read your programs, and I will not read a program that is extremely poorly indented.

A program that is extremely poorly indented will receive a failing grade, regardless of how well it performs the task that it is required to do.

The following are broad guidelines for grading. Many programs will not fit exactly into any of these classifications, but I will try to choose the best fit.

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. Every function should have a clear and correct contract. The program 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, with a contract for each function. 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 (70-79), 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 (60-70), 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.

If you turn in a partial program, I will grade based on roughly what portion has been completed. For example, if you do half of the work, and that half looks good, you might receive a grade of 50%.


Versions of programs

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 for up to one week with a 10 point penalty (out of 100). Assignments that are more than one week late will not be accepted.

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.


Turning in programming assignments

At the top of every source file that you turn in, write a comment including your name, the course (CSCI 3510) the assignment number and the submission (1 or 2). Always turn in all of your source files for each program, even if I provided some of them to you.

You must use the handin utility on Unix systems to hand in programs. Assignments are called 1a, 1b, 2a, 2b, etc. To hand in assignment 1a, consisting of files file1.cc and file1.h, issue command

  ~karl/3510/handin 1a file1.cc file1.h
You can request a listing of the files that you have handed in for assignment 1a using command
  ~karl/3510/handin 1a -list
and you can remove files file1.cc and file1.h that were handed in by using command
  ~karl/3510/handin 1a -remove file1.cc file1.h


Asking questions by email

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.

A good way to ask questions is by email. Please use a subject indicating that you are asking a question for CSCI 3510, and always include your name in your email. A reasonable subject would be

CSCI 3510 question about assignment 3


Weather emergencies

In the event of a weather emergency, information about ECU can be accessed through the following sources:

ECU emergency notices http://www.ecu.edu/alert
ECU emergency information hotline 252-328-0062


Students with disabilities

East Carolina University seeks to comply fully with the Americans with Disabilities Act. Students requesting accommodations based on a covered disability must go to the Department for Disability Support Services, located in Brewster A-114, to verify the disability before any accommodations can be made. The telephone number is 252-328-6799.