Requirements

• 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.

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 (3-4 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

• Best practices (1 week)
  • class design and patterns in C++
  • systematic program development and debugging
  • profiling and optimization

• Concurrency in C/C++ (1 week)
  • concurrent programming beyond HW/SW interface course
  • asychronous I/O, networking, and user interfaces
  • if time, a brief reintroduction to threads

• Security issues in C/C++ (< 1 week)
  • discussed throughout where appropriate, e.g., safe vs unsafe library functions

Assignments

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 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.

Exercises

• 0: (late) or (major incorrectness) or (compilation warnings)
• 1: (major style errors) or (minor incorrectness)
• 2: minor style errors
• 3: perfection: your exercise compiles with no warnings, runs correctly, has no leaks, and has great style.

We expect 0s and 3s to be relatively rare.

Exams

Grades

• assignments: 60%
• exercises: 20%
• sections: 20%

Policies

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

Late Policy: For assignments, there is a 10% penalty for each late day, or portion thereof, up to a maximum of two days late. You will receive a zero for the assignment if it is turned in more than 48 hours late. Also, you get two free late days - two days of lateness with no penalty - to use at your discretion.

For exercises, we will not accept any that are 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: 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 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.