CSE 333 18au - Systems Programming - Overview

[ prereqs | topics | assignments | exercises | exams | grades| texts| policies ]



  • CSE351: rudimentary knowledge of C programming; the ability to write, run, and debug programs; familiarity with Linux and the use of Linux compilation, editing, and debugging tools; a solid mental model of the relationship between high-level code (C) and assembly-level compiled code; simple data structures such as linked lists, trees, hash tables, and queues.


  • Courage and perserverance, even in the face of complexity and uncertainy.

    Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are persistent. (Source: Wikipedia, Extreme Programming)

Approximate topic list

  • C programming (<2 weeks)
    • review of basic C programming and memory model from HW/SW interface course
    • pointers, lvalues & rvalues, structs, casts
    • arrays and strings
    • 2-D arrays with and without pointers
    • dynamic storage allocation (malloc/free)
    • C preprocessor, multifile programs
    • core C libraries (I/O, strings, etc.)
    • idioms for error handling without exceptions
  • Essential tools for C/C++ (1 week)
    • compilers, debuggers, make
    • advance tools (memory leak detection, performance profiling, code coverage)
    • version control, code reviews, unit testing
  • Memory management and system interface (1 week)
    • idioms for manual memory management; avoiding dangling pointers and memory leaks
    • memory management implementation
    • linking and libraries: how a program is assembled
    • relation between libraries and underlying OS services
  • C++ programming (2-3 weeks)
    • basic C++: "a better C", C with classes
    • class definitions, constructors, copy constructors, destructors, const, other details
    • dynamic memory allocation (new/delete), classes with dynamic data
    • classes and inheritance in C++; overloading, overriding
    • using C++ templates and STL
    • smart pointers
  • Best practices (<1 week)
    • class design and patterns in C++
    • systematic program development and debugging
    • profiling and optimization
  • Networking (1 week)
    • TCP/IP overview
    • basics of client-side and server-side programming
  • Concurrency in C/C++ (<1 week)
    • concurrent programming beyond HW/SW interface course
    • asychronous I/O, networking, and user interfaces
    • a brief reintroduction to threads
  • Security issues in C/C++ (<1 week)
    • discussed throughout where appropriate, e.g., safe vs unsafe library functions


This course is designed to give you substantial experience with programming. There will be three or four major programming assignments during the quarter; the assignments are designed to build on top of each other, so it is in your interest to make sure that earlier assignments are rock-solid.

All of our assignments assume you will be programming within a CSE Linux environment. There are three ways to do this:

  • you can log into a Linux PC within one of the undergraduate workstation labs;
  • you can remotely log into the attu.cs.washington.edu cycle servers;
  • you can install VMware on your personal laptop or home machine, and download and use one of the UW CSE home virtual machine images. Note: the gcc compiler toolchain on the CSE linux systems was updated for 18au. Be sure you are using the current version of the VM if you do your coursework there.

Regardless of where you develop your assignments, we will test and grade them on the CSE lab machines or attu, so you must ensure that your code works properly there.


Great programmers write great code. People become great programmers writing lots of code and learningn from the experience. We will be assigning a mandatory programming exercise with most lectures, due before the next lecture. These will be short and simple, but they will reinforce the material from the lecture. We will grade them, but the grading will be course-grained, roughly as follows:

  • 3: an exemplary solution in every way; compiles with no warnings, runs correctly with no memory leaks, has great style
  • 2: a good solution, but not perfect; (minor style errors) or (trivial correctness problems)
  • 1: (major style errors) or (minor incorrectness) or (non-trivial compilation warnings)
  • 0: (late) or (major incorrectness) or (compilation errors)
We expect 0's and 3's to be relatively rare. As with larger assignments, exercises will be graded and evaluated on the CSE linux machines.


We will have one midterm exam and a final exam. The dates will be listed on the course schedule, though the midterm date is subject to change (with reasonable advance notice given).

There is no final exam period in the summer. The final exam will be held the last day of class and will basically be a second midterm.


Grades will be assigned approximately as follows:
  • assignments: 40%
  • exercises: 25%
  • midterm: 15%
  • final: 20%
These percentages may be adjusted if appropriate.


There are no strictly required texts for this courses. Most people will find it useful to have both a C and a C++ reference; suggestions are given below. We strongly recommend that you have a copy of the C++ Primer as C++ is a big, complex language and it is hard to understand how it fits together from google and stack overflow snippets and folklore.

Strongly Recommended (i.e., basically required)


The main course web page has links to several useful C, C++, and Linux reference and tutorial sites.


(Many of these policies are taken verbatim from other CSE courses.)

Late Policy: Assignments are expected to be done on time, however we realize that occasionally a bit of slack is needed for unexpected problems or to get rid of that "last" bug. For the entire quarter, you may have four free "late days". You are strongly advised to save them for emergencies. You may not use more than two for the same assignment, and on group projects (if we have any) you may only use late days if all members of the group have them available, and all members of the group will be charged for each late day used. They must be used in 24-hour (integer) chunks. If you are not finished with an assignment and have no more remaining late days you should turn in your best effort for partial credit either on time or after using any available late day(s). This policy may not be the same as in other classes. You are responsible for understanding it if you choose to submit late work.

For exercises, we will not accept any late; you must turn them in on time.

Reasonableness: No set of rules can apply perfectly in every setting. We will make reasonable exceptions, and in return, we expect you to be reasonable as well.

Cheating vs. Collaboration: Please see the separate discussion of Academic Integrity. You are expected to read and understand every word in that document. Ask first if you have any questions.

Collaboration is a very good thing. On the other hand, cheating is considered a very serious offense and is vigorously prosecuted. Vigorous prosecution requires that you be advised of the cheating policy of the course before the offending act.

For this course, the policy is simple: don't cheat. You know it when you're doing it. We'll recognize it when you do it. As an easy example, sharing assignment solution code with each other is cheating, as is copying homework solutions from any source. As another easy example, relying heavily on some resource (e.g., some example code you found on the Web) without attributing it in your turnin is cheating.

That said, collaborating is, for many people, an effective way to learn. Learning isn't cheating. Helping each other write programs that are not assignments or exercises isn't cheating. Misrepresenting that you've learned something, or done the work that implies you've learned something, almost certainly is.