ICS 65 Fall 2011, Lab Manual

Introduction

This quarter, you'll work on four programming projects, all of which will be written in C++. You will likely discover that the projects increase in size and difficulty as the quarter goes on, but if you spend enough time working on each one, you'll find that your skill level will rise steadily to match the rising difficulty. While I don't assume that any of you will have previous C++ experience, I do expect that all of you have at least a year or so of introductory programming experience, at least partly in Java (equivalent to that gained in the ICS/CSE 21/22/23, ICS H21/H22/H23, or Informatics 41/42/45 sequences). If you don't, I won't ask you to drop the course, but I'll warn you that you may have some catching up to do. Prior C++ (or C) experience is neither required nor assumed, but doesn't hurt; if you have any prior experience, especially in C, you may find that some of the practices you learned in the past are not acceptable in this course.

Acceptable coding practices

Before proceeding with the projects, you'll need to read this document, which describes acceptable coding practices for this course. It explains not only how your code should look, but which language features you may use and which you may not. You are responsible for reading and adhering to the contents of this document! This document is especially important if you have prior experience in C and/or C++; you might be surprised about what features I'm disallowing.

Submitting your projects

When you complete each project, you must submit it to us electronically. Follow this link for a detailed description of how to submit your projects. Understand that we will only accept projects submitted using the procedure described there; we do not accept printed copies of your projects, nor do we accept them via email under any circumstances.

Evaluation of your work

As you work on your projects, it is naturally your primary goal to write a program that works correctly. However, writing a correctly-working program is not your sole objective. Each of your projects will also be evaluated in terms of the quality of your solution, which includes issues such as code organization, modularity, adherence to the acceptable coding practices, clear and consistent spacing, and appropriate documentation. I intend to skim and/or read every line of your code, so anything you can do to make that easier for me will be appreciated. (This is not just a selfish goal on my part; I'd like you to think about writing your code for other people to read, because that's most often what you would be doing in a professional setting.)

So, the scoring of your project will take into account both how well your program works and how well your program was designed and implemented, guided by the following principle:

A program that is 50% correct but 100% well-designed and implemented is just as good as a program that is 100% correct but 50% crap.

With that principle in mind, the following system will be used to score each of your projects on a 100-point scale:

First, your project will be scored for correctness and robustness. This means your program generates the correct output when given valid input, and also gracefully handles erroneous input or unusual situations, barring those that you are explicitly allowed to ignore. Your project will be given an integer score between 0 and 100 during this phase.
Next, your project will be scored for quality of solution, documentation, and style. Points will be deducted for particularly awkward, cumbersome, or inappropriate ways of approaching a problem. Your program should be divided into logical parts using classes where appropriate, each encapsulating a single idea or task. Variables should be named to reflect their function; the names should be meaningful to the reader. Also, you will be required to follow the acceptable coding practices for this course, and will be docked whenever you don't. In this phase, your project will be given an integer score between 0 and 100.
Finally, your overall score will be calculated in the following way:
- Your quality of solution, documentation, and style score will be divided by 100, yielding a score in the range 0.00 .. 1.00.
- The resulting score will be multiplied by your correctness and robustness score, then I'll take the floor of the result, yielding a final integer score in the range 0 .. 100.

Here's an example.

Suppose your project receives a correctness and robustness score of 95/100, and a quality of solution, documentation, and style score of 78/100.
I'll then divide the quality of solution, documentation, and style by 100 (yielding 0.78).
Finally, I'll multiply 95 by 0.78, then take the floor of result, yielding 74.

In this situation, your final project score will be 74/100. (Not so good for a program that's 95% correct. The moral of this story is to be sure you're paying attention to quality.)

Working in pairs

You are permitted, if you wish, to work on any project in pairs. It is not necessary to notify me of the pairings ahead of time, but there are a couple of rules that I'll be asking you to follow:

You are not permitted to pair up with the same person on more than one project. (The motivation here is that I'd like for you to be able to meet and get to know at least four other people in the course. Social networking is powerful.) No exceptions.
Ideally, you should use the "pair programming" technique for all of the work you do with a partner. Pair programming is not just two programmers working separately on a task, with the work divvied up between them. In pair programming, two programmers share one computer. One is the "driver," who controls the keyboard and mouse. The other is the "navigator," who observes, asks questions, suggests solutions, and thinks about slightly longer-term strategies. The two programmers switch roles every 15-20 minutes, the goal being that both members of the pair have complete mental ownership of all the work that's done, even though only one person at a time is typing. This obligates both partners to communicate with one another about what they do and do not understand, with each partner bringing the other one up to speed when necessary. In so doing, both partners have a firmer grasp on what they're doing and, at least as importantly, why they're doing it that way. Not surprisingly, pair programming doesn't really work via instant messenger or email; being in the same room together is an important requirement to benefit from pairing.
When you submit a project that you've worked on with a partner, be sure to list both of your names and IDs in a comment at the top of each file, so that I can be sure to assign both partners credit for the project.

When you partner up with someone, both members of partnership will be given the same grade on the project, except in extreme circumstances, with agreement from both partners. If you're having problems with your partner, contact me, and I'll try to arbitrate a solution to the problem.

Late work

Things happen and ten-week quarters can be unforgiving. It's not unreasonable to expect that you may find it difficult to finish one of the projects on time, even if you're on top of things most of the time. I get emails often from students, saying things like If I just had one more day to work on this, I'd get it done! On the other hand, being consistently behind is a recipe for struggle in this course; we'll be moving quickly, and it will be progressively harder to catch up the farther behind you get.

The best balance between these two realities is that everyone is allowed to have a tough time with a project once this quarter — maybe you underestimated the difficulty of an assignment, maybe you have three midterms and a paper due the same day, maybe you have a sudden outside commitment that can't be avoided. For this reason, I'm offering the following late work policy:

Each student is permitted to submit any one project up to 48 hours late, with no questions asked about why.

You are not required to notify us in advance. We'll be looking for submissions up to 48 hours beyond the deadline of each project.

We'll be tracking this throughout the quarter and, of course, will not grant the extension to anyone more than once. But this should accommodate the unforeseen issues that might otherwise prevent you from finishing a project on time.

Other than this, late work is not accepted in this course.

A few additional clarifications to this policy are:

There is a ten-minute grace period after the due date, allowing you time to get your files submitted to Checkmate. If you submitted our files at 9:08pm for a 9:00pm due date, you're fine. Best not to play with fire, though, if you're already done before 9:00; at 9:11pm, you'll have used up your one-time extension. No exceptions!
The first project that you submit late will fall under this policy; any subsequent project you submit late will not be accepted. (In other words, you can't submit two projects late, then wait to see which one you get a better score on; we won't be grading the second one.)
If any one file is submitted beyond the ten-minute grace period, the entire project is considered late.

Out-of-the-ordinary circumstances sometimes warrant exceptions to this policy; if you are faced with a problem that is preventing you from getting your work done on time, either on a single assignment or chronically, please contact me and we can talk about a solution to it.

You'll also have the option to resubmit one project during the tenth week for a regrade, so you can use this option to simulate the option of submitting late work beyond 48 hours on one project, if you wish.

Code that does not compile

If you submit a program that does not compile, we will not be able to execute it and, thus, will not be able to evaluate its correctness. It is your responsibility to turn in code that compiles. At my discretion, I can assign a score of as few as zero points on the correctness and robustness portion of your project score (and, hence, an overall score of zero) if your program does not compile. At your assumed level of experience, it's not difficult to ensure that code compiles, even in a partially-completed program; make sure you take the time to do it. One way to be safe is to make a backup of your code every time you've successfully added a feature and your program compiles. If you run out of time and have to turn in a partially-completed program, simply turn in the last "good" version of the code.

Development environment

The officially-supported development environment for ICS 65 is Visual Studio 2011. Visual Studio is an integrated development environment, with a wealth of features (mostly relating to Windows and web-based programming) that we will not be using in this course. However, it does offer three features that are of tremendous importance to us:

Its C++ compiler is relatively standards-compliant. No C++ compiler is entirely standards-compliant, but Visual Studio certainly comes close enough for our use. (Some other compilers, such as very old of Visual Studio, don't, especially with respect to newer features such as templates and covariant return types.)
It provides an integrated debugger, allowing you to place breakpoints into your code and step through it line by line, inspecting the values stored in variables as you go along. Debugging C++ can be much more difficult than debugging Java, so the debugger is sometimes essential.
Low cost! Ordinarily, this is an expensive software development suite, but it can be obtained free of charge by all ICS 65 students.
- Bring a blank writeable DVD and you can burn yourself a copy in the lab. Ask the Lab Attendant in CS 364 about it.
- Another option is to use our MSDN Academic Alliance (MSDNAA) account to download the contents of the CD's from the Web. For more information about using MSDNAA, see this FAQ. Accessing MSDNAA will require you to use your ICS account — which, notably, is different from your UCInetID.

There are two versions of Visual Studio available and either of them is fine for your work in this course:

Visual Studio 2011, which is available via MSDNAA.
Visual C++ 2011 Express Edition, which is freely available directly from Microsoft.

(If you already have Visual Studio 2008, that's fine, too; this may also be the version installed in the ICS labs. We will rarely, if ever, do things that require 2011; the only possible exception is if we experiment with some of the features added in the latest version of C++, C++0x, which are only supported in 2011.)

There is a downside to an environment like Visual Studio. With its long list of features comes complexity. Compiling and running a program isn't as easy as using a text editor, typing javac *.java, and typing java MyClassName. To mitigate some of this difficulty, I've written a brief Visual Studio tutorial, which will take you through some of the simple tasks that you'll need to do in this course.

I expect that all of you are already familiar with Java. One of Java's advantages in a classroom setting is its platform-independence. Since Java programs written for one environment (operating system, compiler, etc.) can reasonably be expected to work in any other environment, you're free to choose any Java environment that suits you. The same cannot be said for C++. C++ is (intentionally) not platform-independent. Such fundamental details as the size of an int variable are not the same on all platforms, or even on all compilers for a particular platform. Most, if not all, of the code that we write this quarter will be standard C++; it's likely that if you use another standards-conforming compiler (e.g., GCC) on Windows or another operating system, you'll be fine. However, please be aware that I'll be grading your projects using Visual Studio (on Windows), as provided in the ICS labs. If you intend to work at home using another environment, you're responsible for testing your code with Visual Studio before submitting it.

Useful C++ links

So, you want more information about C++? While there is no "standard" C++ Web site, analogous to java.sun.com, there are some great sites you should check out.

If you have a question about C++, it's very likely that it's been answered in Marshall Cline's C++ FAQ Lite. (If not, it's probably been answered in his extensive companion book, the C++ FAQ Book, but the Book is not available on-line for free.)

If you need reference material about the Standard C++ Library, check these links:

Rogue Wave Software's Standard C++ Library User Guide
SGI's Standard Template Library Programmer's Guide
cppreference.com
The Standard Template Library, a definitive reference by Alexander Stepanov (the author of the STL)

A brief C++ bibliography

I used the following books during my preparations for this course the first time I taught it, thanks in large part to the generosity of Addison-Wesley. I'm sure there are plenty more good C++ books out there, but these are the ones I used on at least a semi-regular basis for at least three months while setting this course up for the first time, and still need from time to time.

The C++ Programming Language: Special Edition by Bjarne Stroustrup. Addison-Wesley 1997. There's hardly a question about C++ that couldn't be answered with this book. However, it can be a bit of a difficult read; prior knowledge about C (or even earlier versions of C++) is a plus, but not a must. When I need to understand some dark corner case, this is the book I go to first. When I want a succinct explanation of a concept, this is a book that I only sometimes use. Not for the beginning programmer.
The Design and Implementation of C++ by Bjarne Stroustrup. Addison-Wesley 1994. This book presents a detailed, informative, and very interesting history of C++, from its humble beginnings as C with Classes until the standardization process was partially finished. If you're looking for insight about why a particular C++ feature was designed the way it was, or you'd just like to gain an understanding about why programming language design is harder than it seems, this is the right book for you. (This would be a great book to read after this quarter is over.)
C++ Templates: The Complete Guide by David Vandevoorde and Nicolai M. Josuttis. Addison-Wesley 2003. A very detailed and up-to-date view of C++ templates, as defined in Standard C++. The first half of the book explains the syntax and semantics, while the second half explores patterns for using templates to solve real problems. Not a light read, by any stretch, but an excellent reference if you want to learn more about templates.
STL Tutorial and Reference Guide, Second Edition by David R. Musser, Gillmer J. Derge, and Atul Saini. Addison-Wesley 2001. A complete reference for the Standard Template Library, which is now officially a part of the Standard C++ Library. Explains some of the "why" in addition to the "what" regarding the STL. Reference-wise, there's not a lot of information here that can't be found in on-line references such as the ones I listed in the previous section, though sometimes it's nice to have it in book form, or to have higher-level explanations of the design concepts behind the library.
The Annotated C++ Reference Manual by Margaret A. Ellis and Bjarne Stroustrup. Addison-Wesley 1990. This book is a bit out-of-date now, but it does contain some of the deep, dark language rules, as well as some justification for why they are they way they are. This is the only book I could find that completely defined the rules for resolution of overloaded functions, for example.
Absolute C++, 4th edition by Walter Savitch. Addison-Wesley 2009. This is the textbook for our course. I refer to it mostly to be aware of what it says and how it affects our course. There's little information within that can't be gotten from other books that are more reference-style, but few reference books make things as clear for novices as this one does.

Academic honesty

The policy

As ICS 65 students, you are expected to know and follow the academic honesty policies of both the Bren School of ICS and the University as a whole. Please take a few minutes to read the policies, which can be found at this link.

All of your lab work is expected to be completed solely by you (and your partner, on paired assignments). Worker in larger groups and/or sharing of code between students that are not partners is not permitted. Note that "high-level discussion of course material for better understanding" is permitted and encouraged, but when it comes time to sit down and write code, that is expected to be done by you and you alone. All submissions are compared to one another using an automated plagiarism detection system. This system is extraordinarily good at finding similarities between submissions, even when there are superficial differences. (Note that we also compare your submissions to those submitted during previous quarters whenever one of these assignments was given during a previous quarter, so it is an exceedingly bad idea to turn in, or even refer to, code written by a friend of yours who took the course already.)

Since all of your work is expected to be completed solely by you (and your partner, on paired assignments), you will be held responsible even if you plagiarize only a small portion of someone else's work.

You are not permitted to reuse code that you wrote along with a partner during a previous quarter. You may only reuse code that you wrote on your own, and you may only reuse it for a project that is not paired this quarter. (The reason for this rule is simply that I do not want students repeating the course to pair up with someone new and deprive them of the opportunity to work on the project. Besides, if you're repeating the course, it's generally a good idea to start fresh, to solidify the ideas you missed the first time around.)

Academic honesty is a two-way street. Providing your code to other students for them to turn in as their own is not permitted anymore than turning in someone else's code. Resist the temptation to give code to your friends "for reference." Based on my experience, I can say that your "friends" may very well betray you and turn it in, anyway.

Violators of academic honesty policies are subject to the penalties described in the Bren School of ICS policy. They are also subject to an immediate course grade of F, and you will not be allowed to drop the course to avoid the grade. Also be aware that a single documented case of academic dishonesty may preclude you from switching into computing majors, registering for computing minors, joining the ICS Honors Program, and graduating from a computing major with honors.

The lesson

Okay, so the moral of the story is that it's wise to avoid cheating. I believe that it's relatively rare that students enter a course with the conscious intent to cheat their way through it; why come to UCI if you're not planning to get something out of the coursework? So why do people cheat every quarter in every course? The answers vary, but here's the easiest way I can boil down the numerous conversations I've had with students caught cheating in my courses over the years: I fell behind and couldn't figure out how to catch up. Things happen and ten-week quarters are unforgiving. You might get sick, you might have issues crop up in your family, you might have an off-campus job that's demanding too much of your time, you might be trying to decide whether you're on the path you want to be on... Any of those things (and many others) can make it hard to keep up. You fall a little behind, you fall a little further behind, and pretty soon the situation seems hopeless. You're under pressure, temptation gets the better of you...

If you feel like you're beginning to slip off course or things are getting beyond your control, the best thing to do is to talk to us sooner rather than later. We're here to help; we understand. But the reality of taking large-sized courses at a large-sized institution is that we're not going to know you're in need unless you tell us. If things are happening in your life, tell us; you don't have to be specific if you're not comfortable with it. Before the fact, there's often a way to work things out. After the fact, it's usually too late.