Syllabus

Course Description

Includes substantial programming experience in languages that expose machine characteristics and low-level data representation (e.g., C, C++); explicit memory management; interacting with operating-system services; and cache-aware programming.

Prerequisites:

  • CSE351 (The Hardware/Software Interface): CSE 351 provides students with 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.
  • CSE 143 (Intro Programming II): CSE 143 is not a direct prerequisite (CSE 351 prerequisite), but some of its topics are beneficial to review for CSE 333. This includes classes, inheritance, good style practices, and simple data structures such as linked lists, trees, hash tables, and queues. Further knowledge of Java and these data structures is not required, but could be helpful!

Course Learning Objectives

At the end of this course, students should be able to:

  • Write C/C++ code using pointers to create and manipulate complex data structures;
  • Debug significant C/C++ programs using GDB and Valgrind;
  • Read and write basic Makefiles;
  • Explain the process of making a system call;
  • Describe fundamental differences between C and C++;
  • Write programs that interact with files, directories, and the network using the POSIX library;
  • Write multi-threaded C programs using pthreads;
  • Display courage and perseverance, even in the face of complexity and uncertainty.

Course Materials

CSE Linux Environment

All assignments in this class will be graded on the CSE Linux environment. We strongly recommend that you work on the assignments in this same environment. There are three ways to do this:

  1. Log into a Linux PC located in one of the undergraduate workstation labs
  2. Remotely log in to attu.cs.washington.edu
  3. Install and use the CSE Linux VM on your personal machine

Gitlab Repository

You will be given a private repository on the CSE Gitlab to use throughout the quarter. Project ("homework") files will be pushed to your repo and then submitted for you to Gradescope. We strongly recommend using your repo for version control for all assignments and to facilitate sharing if you have a partner.

Textbooks

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. The C++ Primer is strongly recommended as C++ is a big, complex language and it is hard to understand how it all fits together from just Google and Stack Overflow snippets and folklore.

Strongly Recommended:

Suggested:


Approximate Topic List

  1. C Programming (< 2 weeks)
    • Review of basic C programming and memory model from 351
    • Pointers, 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
  2. Essential Tools for C/C++ (1 week)
    • Compilers, debuggers, make
    • Advanced tools (memory leak detection, performance profiling, code coverage)
    • Version control, code reviews, unit testing
  3. 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
  4. 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
    • C++ templates and STL
    • Smart pointers
  5. Best Practices (< 1 week)
    • Class design and patterns in C++
    • Systematic program development and debugging
    • Profiling and optimization
  6. Networking (1 week)
    • TCP/IP overview
    • Basics of client-side and server-side programming
  7. Concurrency in C/C++ (< 1 week)
    • Concurrent programming beyond 351
    • Asychronous I/O, networking, and user interfaces
    • Brief reintroduction to threads
  8. Security Issues in C/C++ (< 1 week)
    • Discussed throughout where appropriate, e.g., safe vs unsafe library functions

Course Components

  1. Lectures: There will be 28 lectures. Attendance and participation is expected at all of them.
  2. Exercises: People become great programmers by writing lots of code and learning from the experience. We will be assigning a mandatory programming exercise after every few lectures, due in ~2-5 days. These will reinforce the material from lecture.
  3. Project ("Homework"): This course is designed to give you substantial experience with programming. There will be 4 major programming assignments during the quarter that build on top of each other.
  4. Exams: There will be a midterm and a final exam – see the Exams page for dates.

Policies

Grading Policies

Your grade in the class will be broken into the following components:

  • Exercises: 30%
  • Homework (Projects): 43%
  • Midterm Exam: 12%
  • Final Exam: 12%
  • Effort, Participation, and Altruism: 3%

We will use an approximate "straight-scale" grading scheme:

  • 96.5% → 4.0, 88.5% → 3.5+, 80% → 3.0+, 70% → 2.5+, 60% → 2.0+

EPA: Effort, Participation, and Altruism

You can earn "points" for each of the following:

  • Effort: Attending section and office hours; keeping up with Ed Discussion.
  • Participation: Participating during lecture and section, including completing lecture polls and interacting with TAs and other students; asking questions and commenting on Ed Discussion.
  • Altruism: Helping others in section, during office hours, and on Ed Discussion.

Lecture Polling

You will receive credit for voting on multiple choice questions in lecture. This quarter we will be using Poll Everywhere, which you should have open during lecture (whether live or recorded).

  1. Register your UW NetID on the . More information can be found from .
  2. Optionally, you may download the Poll Everywhere .
  3. Bring an Internet-enabled device with you to lecture.

Assignment Policies

Collaboration, Submission, and Grading

  • Exercises may be worked on with a partner. They are submitted to (the interface allows you to add your partner to your submission) and graded using the following categories:
    • Correctness [3 pt]:  Meeting the exercise specifications – produces the desired output for all specified inputs, reasonably handles bogus inputs, doesn't segfault, and doesn't run infinitely.
    • Tools Check [2 pt]:  Based on compiler warnings, valgrind output, and disallowed linter messages.
    • Style [3 pt]:  Code style and quality, including code organization and generalizability, naming conventions, error checking, and matching provided code.
    • A submission that is late or doesn't compile on the CSE Linux environment will automatically receive a score of 0
  • Homework may be worked on with a partner (highly encouraged!). They are distributed and submitted via . To submit, you must push a tag that ends with -final (e.g., hw2-final). For partnerships, you will need to submit to a Google Form for each assignment to indicate whose repo to submit from. Your tagged commit will be uploaded for you to Gradescope and graded on a combination of test suite scores, manual user testing (where applicable), and style grading.
  • Exams are taken individually. These will be take-home and consist of typing responses into text boxes via the web interface. Each individual question has a "Save answer" button which will submit for you. You can enter and leave the exam and submit as many times as you want to during the exam window. The course staff will manually grade your final submission. See the for more details.

Deadlines and Late Policies

For a list of all assignment due dates (deadline times specified below) in one place, see the . Please contact the instructor as soon as possible (preferably in advance) if you encounter or foresee any difficulties meeting deadlines for reasons that are beyond your control (see our extenuating circumstances policy below for more details).

  • Exercises are due at 11:00 am 2-3 lectures after they are released. This allows us to release sample solutions later that day for review and comparison. Because of the release of sample solutions, no late submissions are accepted.
  • Homework are due at 11:59 pm on the specified dates and you are allocated a total of 4 late day tokens to remove late penalties as you accumulate late days throughout the quarter. These tokens are intended for alleviating unexpected emergencies and scheduling difficulties with the rest of your classes and life; we strongly encourage you to treat them as such to help you keep pace with the rest of the course material and assignments.
    • A late day is defined as the 24 hour period after a homework's due date: num_late_days = ceil(hours_late / 24).
      • An exception is made for weekends, which count as a single late day. That is, if an assignment is due at 11:59 pm on Friday, submitting before Sunday at 11:59 pm counts as only ONE day late (submitting by 11:59 pm on Monday would count as TWO days late).
    • Homework submissions are NOT ACCEPTED more than two days late.
    • There is no bonus for having leftover late day tokens at the end of the quarter.
    • At the end of the quarter, if your late day total exceeds the late day tokens afforded to you, you will be penalized 10% of your assignment score for each remaining late day. Only homework submitted late are eligible to be penalized and cannot be penalized more than twice, and we will apply the minimal penalty possible.
  • Exams are due at 11:59 pm on the specified dates. No late submissions are allowed; you should make sure to submit incomplete responses for potential partial credit.

Academic Conduct

In general, we encourage , but there is a very fine line between collaboration and cheating. We can learn a lot from working with each other and it can make the course more fun, but we also want to ensure that every student can get the maximum benefit from the material this course has to offer. Keep in mind that the overall goal is for *YOU* to learn the material so you will be prepared for the exams, future courses, job interviews, etc. in the future. Cheating turns the assignments into an exercise that is a silly waste of both your time and ours; save us all by not doing it.

Cheating consists of sharing code or solutions to assignments by either copying, retyping, looking at, or supplying a copy of a file. Examples include:

  • Coaching a friend to arrive at a solution by simply following your instructions (i.e., no thinking involved). An example is helping a friend write a program line-by-line.
  • Copying code or answers from a similar course (previous quarters of 333 or from another university).
  • Using solutions/code from the web directly or as a starting point, including GitHub, Chegg, and AI generative tools like ChatGPT.
  • Communicating your solution with another student via electronic or non-electronic means.

Cheating is a very serious offense. If you are caught cheating, you can expect the initiation of an academic misconduct case in the University system and a grade penalty, if found guilty. Cheating is an insult to the instructor and course staff, to the school and program, and most importantly, to you and your fellow students. If you feel that you are having a problem with the material, or don't have time to finish an assignment, or have any number of other reasons to cheat, then please reach out to the instructor ASAP! Just don't cheat.

If you are in doubt about what might constitute cheating, contact the course staff via email or private post describing the situation and we will be happy to clarify it for you. For more information, you may consult the school's .


Disability Resources

The is a unit within the Division of Student Life and is dedicated to ensuring access and inclusion for all students with disabilities on the Seattle campus. They offer a wide range of services for students with disabilities that are individually designed and remove the need to reveal sensitive medical information to the course staff. If you have a medical need for extensions of exam times or assignment deadlines, these will only be granted through official documentation from DRS. Browse to to start the process as soon as possible to avoid delays.

You can refer to the university policies regarding for more information.


Religious Accommodations

Washington state law requires that UW develop a policy for accommodation of student absences or significant hardship due to reasons of faith or conscience, or for organized religious activities. The UW's policy, including more information about how to request an accommodation, is available at . Accommodations must be requested within the first two weeks of this course using the .


Extenuating Circumstances and Inclusiveness

We recognize that our students come from varied backgrounds and can have widely-varying circumstances. If you have any unforeseen or extenuating circumstance that arise during the course, please do not hesitate to contact the instructor in office hours, via email, or private Ed Discussion post to discuss your situation. The sooner we are made aware, the more easily these situations can be resolved. Extenuating circumstances include work-school balance, familial responsibilities, military duties, unexpected travel, or anything else beyond your control that may negatively impact your performance in the class.

Additionally, if at any point you are made to feel uncomfortable, disrespected, or excluded by a staff member or fellow student, please report the incident so that we may address the issue and maintain a supportive and inclusive learning environment. Should you feel uncomfortable bringing up an issue with a staff member directly, you may consider sending or contacting the .