Allocator

Due: Thu, 7 Mar 2013, 8pm
80 pts, 8% of total grade.

Specification

Design and implement a set of functions to manage a heap (free store) in C++.

For all projects, the minimum requirement for getting a non-zero grade is to write standard-compliant C++ and to satisfy all of the requirements in the table below, including the precise naming of all the files.

You can earn 5 bonus pts, if you work with a partner using pair programming and vouch for the fact that you worked on the project together for more than 75% of the time.

Only one solution must be turned in for the pair. If two solutions are turned in, there will be a 10% penalty, and the later one will be graded.

Bonus pts will not increase the total score beyond the max score.

You may not use new, delete, malloc(), free(), or allocator. You may use the STL.

Analysis

These are additional descriptions:

Tools

Requirements

Points Description Files Submission
1 5 pts Git Repository
Set up a private Git repository at GitHub, named cs371p-allocator.
Invite the grader to your repository. Commit at least 5 times. Commit once for each bug or feature. If you cannot describe your changes in a sentence, you are not committing often enough. Write meaningful commit messages and identify the corresponding issue in the issue tracker (below). Create a log of the commits. Push frequently. It is your responsibility to protect your code from the rest of the students in the class. If your code gets out, you are as guilty as the recipient of academic dishonesty. 		Allocator.log GitHub
Turnin
2 5 pts Issue Tracker
The GitHub repository comes with an issue tracker.
Create an issue for each of the requirements in this table. Create an issue for each bug or feature, both open and closed. Describe, label, and prioritize each issue adequately. Create at least 10 more issues in addition to the requirements in this table. 		GitHub
3 30 pts Unit Tests
The grader's GitHub account will have a public Git repository for unit tests and acceptance tests.
It is critical that you clone the grader's public repo into a different directory than the one you're using for your private repo.
Write unit tests before you write the code. When you encounter a bug, write a unit test that fails, fix the bug, and confirm that the unit test passes. Write at least 3 unit tests for each function. Tests corner cases and failure cases. Name tests logically. Push and pull the unit tests to and from the grader's repository. Prepend <cs-username>- to the file names at GitHub (i.e. foo-TestAllocator.c++ and foo-TestAllocator.c++.out). Reach consensus on the unit tests.
You must use Valgrind. 		TestAllocator.c++
TestAllocator.out 		GitHub
Turnin
4 35 pts Implementation
Use assert to check pre-conditions, post-conditions, argument validity, return-value validity, and invariants. Worry about this last, but your program should run as fast as possible and use as little memory as possible. 		Allocator.h GitHub
Turnin
5 5 pts Documentation
Use Doxygen to document the interfaces.
The above documentation only needs to be generated for Allocator.h. Comment each function meaningfully. Use comments only if you need to explain the why of a particular implementation. Choose a coding convention and be consistent. Use good variable names. Write readable code with good indentation, blank lines, and blank spaces. 		html/* Turnin
6 Submission
Rename "makefile.c++" to "makefile".
Fill out the Google form and submit the ZIP file to Turnin. 		makefile.c++
Allocator.zip 		Google
Turnin

Grader

Name GitHub ID GitHub Test Repository Turnin ID Turnin Project Folder Google form
Reza Mahjourian rezama cs371p-allocator-tests reza cs371ppj3 Google form

Submission

Submit a single ZIP file, named Allocator.zip, to the grader's Turnin account, with the following files:

  • html/*
  • makefile
  • Allocator.h
  • Allocator.log
  • TestAllocator.c++
  • TestAllocator.out

Use CS371p.sh to verify.

  • 1637 reads