CPSC 427/527 Programming Assignments

Submissions

Assignments are due at 11:59pm on the date listed unless otherwise noted. Submissions must be done from your Zoo account and grades will be determined by how submissions behave on the Zoo machines. See below for instructions for using the submit system.

Each submission must also have a makefile and a log file (see below for log file requirements).

Late Policy

There is an automatic two-hour grace period for each programming assignment. Beyond that, late submissions with no Dean's excuse will incur a 5-point penalty for each 12-hour period after the assignment is due. Submissions will not be accepted more than 120 hours late, nor after the end of reading period. Each student's first 50 lateness points for the semester will be forgiven. The only way to get more is with an official note from your Residential College Dean.

Assignments

Project	Due Date (yyyy-mm-dd)	Description
1	2019-01-29	Distance calculator
2	2019-02-07	SpinOut
3	2019-02-21	Matrix Class Template
4	2019-03-07	STL
5	2019-04-04	Yahtzee
6	2019-04-11 2019-04-16	Yahtzee variant (delivered to Zoo submission directory)
7	2019-04-25	Go Simulation

General Requirements

• All source code should be easily comprehended, with adequate and consistent spacing, concise but descriptive idenitifiers, comments before long sequences of code, and enumerations and constants favored over literals.
• Submissions should be modularized, with collections of related functions and methods divided into separate files. Generally this means that each class that is intended for external use should have its own header and implementation files declaring and defining its members and related functions.
• Header files should be written so that they can be #included regardless of what other files have been #included -- if a declaration is required by your header files, then #include the appropriate header file in your header file (or write a forward declaration in your header) rather than relying on your #includers to have already #included those header files before they #include yours.
• You should use C++ libraries and constructs rather than the corresponding C libraries and constructs where possible (for example, use cin and cout with the I/O operators << and >> rather than printf and scanf).
• Each public member of a class should be documented with a comment before it in the header file. For a method the comment should include 1) a description of the parameters including any limitations on the values allowed (preconditions), and 2) a description of what the function does and/or what it returns (postconditions).
• Things that make sense to be declared as const should be declared as const.
• There should be no warnings when your code is compiled with the -Wall, -std=c++17, and -pedantic options.

Log Files

Each submission should include a log file that contains

• your estimate of the time required (made prior to writing any code),
• the total time you actually spent on the assignment,
• the names of all others (but not members of the teaching staff) with whom you discussed the assignment for more than 10 minutes, and
• a brief discussion of the major conceptual and coding difficulties that you encountered in developing and debugging the program.

To facilitate analysis, the log file MUST be the only file submitted whose name contains the string "log" and the estimate and total MUST be on the only line in that file that contains the string "ESTIMATE" / "TOTAL".

Assignments with missing or incomplete logs will be subject to a penalty of up to 5%.

General Rules for Passing Automated Tests

• The should be no output to standard output or standard error beyond what is specified in the assignment descriptions.
• Programs should exit gracefully. For C/C++ that means, among other things, no asserts or (C++) uncaught exceptions.
• valgrind should report no errors.
• Test what is actually in the submission system using makeit and testit (see below).

The submit Program

The submit program can be invoked in nine different ways:

% /c/cs427/bin/submit  1  Makefile tokenize.c unique.c time.log

submits the named source files as your solution to Homework #1;

% /c/cs427/bin/check  2

lists the files that you have submitted for Homework #2;

% /c/cs427/bin/unsubmit  3  error.submit bogus.solution

deletes the named files that you had submitted previously for Homework #3 (i.e., withdraws them from submission, which is useful if you accidentally submit the wrong file);

% /c/cs427/bin/makeit  4  tokenize unique

runs "make" on the files that you submitted previously for Homework #4;

% /c/cs427/bin/testit  5  NameOfExecutable

runs the public test cases on the files that you submitted previously for Homework #5;

% /c/cs427/bin/protect  6  tokenize.c time.log

protects the named files that you submitted previously for Homework #6 (so they cannot be deleted accidentally);

% /c/cs427/bin/unprotect  7  unique.c time.log

unprotects the named files that you submitted previously for Homework #7 (so they can be deleted); and

% /c/cs427/bin/diffit  8  unique.c time.log

uses /usr/bin/diff to compare the named source files with the versions that you submitted previously for Homework #8; and

% /c/cs427/bin/retrieve  9  Csquash.c

retrieves copies of the named files that you submitted previously for Homework #9 (in case you accidentally delete your own copies).