C++ Project Autumn 2014
A custom String class of your own
Define, implement, and test a
class String, in the style of the standard STL containers.
String must provide (at least) the following features:
-
standard data-type operations: constructors, assignment, and destruction
-
access to its characters (if any) via an overloaded operator [].
-
STL-style iterators to traverse the contents of a String
-
insertions and deletions:
push_back(), pop_back(), insert(), erase()
-
swap() to exhange the contents of two strings
-
overloaded input and output operations
- lastly, you need to write a test driver for your String class
Here is link to example c++ code that demonstrates how the Strings are supposed to be used in real programs:
strings.cpp
Technical requirements
Provide the class with a self-check capability
(a check() function that verifies the class invariant).
Check pre-conditions and post-conditions systematically,
and handle all errors in a consistent manner.
You may not use any standard containers provided by the language,
but start the implementation from scratch.
Implement your String as a regular class (not as a template).
The function definitions must be separately compiled, i.e.,
your "string library" is divided into a header file and a separate implementation file.
The use of STL containers (like vector) is not allowed in the implementation. Use the C++ facilities
for allocating/deallocating storage from the free store for the internal dyncamic objects of your String implementation.
You are expected to properly apply and use all the relevant idioms, patterns, and
guidelines given during the course. E.g., remember to make your class const correct.
Emphasize correctness, modularity, maintainability, and safety
(instead of absolute efficiency).
Write a short report on the assignment, in English.
Verbally describe the problem and your solution.
Don't copy declarations and definitions from the program -
your code should be self-documenting.
Instead, report things that are not so self-evident from the program code.
These include explanations of solutions or decisions, the overall
organization or dependencies, and tricky problems or interesting experiences.
The report should clearly show that you recognized the relevant
problems and found your solutions to them.
Report any remaining errors, shortcomings, or limitations of your implementation.
Practice test-driven development:
write all the tests first, as part of the design of the data structure.
Then write the implementation code that makes these tests pass, one by one.
Write your own test driver to ensure the correct behaviour of the class
(you may not use any existing unit testing tool).
Remember that pre-condition checks are an essential part of well-defined library components.
Also, use assertions (post-conditions) liberally.
These help to identify and locate problems near the place where they are born.
Don't depend on manually inspecting results or output, but
create non-interactive self-contained tests that create their own data
and check the expected results.
Remember that a "test failure" means a successful bug discovery. Especially,
- define the expected return values and programmatically check them
with a suitable helper routine (defined in the test driver, e.g., checkSame (result, expected))
- a necessary (but not necessarily sufficient) requirement is that tests
execute each part of the source; so, every function must be tested (at least) once
- check that exceptions are thrown on pre-condition violations and other errors
(on purposely faulty calls/input values)
- catch these exceptions in the driver - and continue with tests
- test overloaded IO operations using std::stringstreams
(since the test driver is not an interactive application)
- remember to free any allocated memory
- use leak detection facilities (your own/3rd party); e.g., simply sum allocations and releases
- remember to use the correct variant of delete/delete[]
- remember that end() does not point to the last element but beyond it
- catch any last escaping "stray" exceptions in the main (eventually there should
not be such exceptions)
- replace ANSI C assert by your own custom "Assert"
that throws exceptions, as Java assert does
(since C assert aborts testing!)
- #defining NDEBUG should turn your own Assert off (to remove extra debugging code)
- at the end of a run, the driver reports the total number of failures - or success!
- make the test driver optionally print out each failure (but still continue with testing)
- consider adding a textual diagnostic to your assertion/check statements
(to be printed out on a log file and/or a console)
Finally, you must run the tests with debugging set off ("NDEBUG") - for the
final "production" version of your software.
Delivering your work
Follow the following instructions how
to format and package your work for delivery.
Store all your files in a directory named according to your unique department user name.
A subdirectory "\src" should contain only C++ source files (headers and .cpp files).
Before creating the package, you remove all the target files
(object files and the compiled program, etc); they are not necessarily
portable from machine to machine.
Put the project report (.pdf file) into its own subdirectory "\doc".
<username>
./src
./doc
The .pdf file containing the project report must contain
the necessary identification information: the course, the date, and the name of the author.
Then zip the whole directory structure as one zip file.
Use a generally available ZIP tool and format; if in doubt, consult your exercise assistant.
You must deliver your work by e-mail to your exercise assistant,
due at the appointed date.
The zip file must cleanly extract as a new directory uniquely named (by your
user name), and containing C++ source files (only) and
the .pdf report in their own subdirectories.
It is advisable to try unpacking the package under an empty directory to
make sure it works.
And also compile and test the program in this new location.
When sending the package by e-mail, put an extra copy of the
mail message to yourself,
to see that your mail message really contained the necessary attachment.
Project deadline
The assignment is due at 09:00 o'clock (9 a.m.) on
Monday, 15 Dec 2014.
Assignments may be returned after this deadline until the end of Thursday, 18 Dec, but the maximum points awarded will be halved. After 18 Dec, assignments are not accepted.
The grading will be 14 exam points maximum for assigments returned on time (by 09:00 Dec 15) and 7 points for those returned late (by end of 18 Dec).
Emphasis in the grading will be laid on correctness,
C++ style rules, modularity, and the design and coverage of your test driver.
Remember to avoid Java-like style and
aim at using proper C++ idioms and constructs.
More detailed instructions and the requirements for the assignment are
given in the exercise groups.
(Any special arrangements must be discussed and agreed on with the assistant.
Of course, the exercise assistant is not obliged to agree upon any such suggestions.)