CSE 333 Syllabus and Course Policies

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 123 (Intro to Computer Programming III): CSE 123 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.

Textbooks

There are no 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 generative AI snippets and folklore.

Strongly Recommended:

• C++ Primer (5th Edition), Lippman, Lajoie & Moo. ISBN 0-321-71411-3.

Suggested:

• C Programming Language (2nd Edition), Kernighan & Ritchie. ISBN 0-13-110362-8.
  • The definitive book on C from the people who created it. You will want to use an online reference for information about the latest libraries, but every serious programmer should study this book.
• Computer Systems: A Programmer's Perspective (3rd Edition), Bryant & O'Hallaron, ISBN 0-13-409266-X.
  • Useful review of CSE 351 and background for many additional topics covered more extensively in CSE333.
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition), Scott Meyers. ISBN 0321334879.
• Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14, Scott Meyers. ISBN 1491903996.

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: Unless there is a university holiday, lectures are held on Monday, Wednesday and Friday during the normal 10 weeks of the quarter. 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 ~4-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.

Grading Policies

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

• Exercises: 30%
• Homework (Projects): 40%
• Midterm Exam: 14%
• Final Exam: 14%
• Effort, Participation, and Altruism: 2%

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 Poll Everywhere website. More information can be found from IT Connect.
2. Optionally, you may download the Poll Everywhere mobile app.
3. Bring an Internet-enabled device with you to lecture.

Assignment Policies

Collaboration, Submission, and Grading

• Exercises are done individually. The first few are submitted to Gradescope, and the rest will be submitted via a Gitlab tag ending with -submit (e.g., ex10-submit).
  • They are graded (in the CSE Linux environment) 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 errors/warnings and valgrind output.
    • Style [3 pt]:  Code style and quality, including code organization and generalizability, naming conventions, error checking, and matching provided code. Partially checked with a linter.
  • We will drop your lowest TWO exercise scores from the quarter.
• Homeworks are completed individually. They are distributed and submitted via Gitlab. To submit, you must push a tag that ends with -submit (e.g., hw2-submit). 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 in person, on paper, and taken individually. Your exam will be scanned and uploaded to the Gradescope web interface. The course staff will manually grade your final submission. See the Exams page for more details.

Deadlines

• Exercises are due at 11:00 AM on the date specified in their spec, usually 1-2 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.
• Homeworks are due at 11:59 PM on the date specified in their spec, usually 2 weeks after they are released.

For a list of all assignment due dates (deadline times specified below) in one place, see the Assignments page. Submission times are determined by the max of the timestamp for your tagged commit and the time that commit was pushed to GitLab.

Careless errors

We all make silly mistakes that need one or two small lines of code changed to make an assignment go from "fail-to-compile" to "passing-all-tests-perfectly." If you made such a mistake, you can request that TAs "fix" your submitted commit when they grade it. These requests will not incur the "decaying" late penalty described below, but may carry a flat penalty of their own. These requests will be accepted on a case-by-case basis and you should not expect them.

There are two categories of careless error we consider:

• Mis-tags: You used the wrong tag name in your git commit history, or tagged the wrong commit. If granted, these requests will carry no penalty. These requests can only be granted if there are GitLab push logs verifying the commit timestamps.
• Code alteration: You submitted (very slightly) broken code, and a TA has to manually make changes to the contents of your source code to get it to copmile. If granted, these requests will carry a 20% penalty (that is, your grade will be multiplied by .8)

Late Policy

All assignment due dates are non-negotiable without a priorly granted extension (see “Extenuating Circumstances” below). For assignments where late work is accepted, it is penalized by multiplying your grade by a “penalty.” The penalty starts at 1 on the due date and decays to 0 over the course of 48 hours. The decay is shaped like a "soft staircase" so that you are effectively not penalized by submitting your work 10 minutes late, but as time goes on your maximum grade will decrease until it drops to 0.

Shown graphically, the penalty multiplier looks like this:

The exact penalty is calculated with the formulas below. Times are measured at a minute granularity. $$ lateness = \frac{turnin\_time-due\_time}{2\ days} \\ \\ lateness' = 2 \pi * 4 * lateness + 0.4 \\ \\ f(\theta) = \theta - sin(\theta) \\ \\ stair = 1 - \frac{f(f(f(lateness')))}{60} \\ \\ decay = 1 - (lateness-0.05)^{40} \\ \\ late\_grade = grade * clamp(stair * decay, 0, 1) $$

This formula looks arbitrary — and it is! — because it was designed to make turning in work a few hours late No Big Deal™, while turning it in close to when we start grading to be an Unfathomable Eldritch Terror®.

Plan ahead, you’ll be alright.

Academic Conduct

In general, we encourage collaboration when learning and debugging, 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.

Permitted collaboration

• Lecture Polls: Collaboration and discussion is encouraged to help you build mastery of the course material.
• Exercises: Exercises are to be completed individually. This will get you the hands-on experience and repetition writing and debugging C/C++ code that will prove invaluable working with the larger code bases of the homework. You can discuss high-level approaches and resources with other students, but no code should be open or visible.
• Homework: Homework is to be completed individually. Collaboration should be restricted to high-level discussion (i.e., ideas only). A good rule of thumb is that you should never show your own code while helping another student (viewing their code is highly discouraged, as it often leads to problematic situations).
• Exams: Exams are taken individually and any attempt to use unpermitted resources or copy off of another student's exam will be heavily punished.

Cheating

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 Academic Misconduct Policy.

Disability Resources

The Disability Resources for Students (DRS) 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 DRS getting started to start the process as soon as possible to avoid delays.

You can refer to the university policies regarding Disability Accommodations 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 Religious Accommodations Policy. Accommodations must be requested within the first two weeks of this course using the Religious Accommodations Request form.

Extenuating Circumstances

Given extenuating circumstances, the instructor may grant a policy exception on a case-by-case basis. A policy exception is one of the following:

• Waiving the late work penalty
• Waiving the assignment score from your grade calculation (only if you cannot complete the assignment before solutions are released)
• Rescheduling an exam date

The following is a non-exhaustive list of reasons that do not give cause for an exception:

• Getting sick, unless you were literally hospitalized
  • There is no reasonable way to judge how sick is “sick enough” for an exception. We don’t want to put you in the position of begging for points, and we don’t want to put course staff in the position of having their hearts twisted trying to decide what to do. If you become unpredictably ill, turn in whatever partial work you’re able to complete and do your best on the remaining assignments. No partial grade is going to make or break your GPA.
  • The one exception is chronic illness, assuming that you talk with the instructor at the beginning of the quarter about it. See below for more.
• Computer trouble or network outages
  • Computers break. Websites go down. Shared servers like Attu get slow when lots of people use them at once. These challenges are predictable enough. Submitting your work close to the due date means you accept the risk that one of these obstacles may cause your work to incur a late penalty.
  • If your computer or internet access regularly interferes with your ability to do assigned work, we want to help you. Please reach out to both your undergrad advisor and the instructor so we can discuss workarounds. Note that this is still not a cause for policy exceptions.
  • If a technical issue prevents the majority of your classmates from submitting their work by the due date, a class-wide exception may be considered by the course staff.
• Career-related engagements like work schedules, conference travel, job interviews or startup meetings
  • For homework assignments, these things are predictable and you can plan ahead knowing how they might affect you.
  • For exams, we will hold them either during class or at a registrar-scheduled exam time. You are expected to be available during these times. If you cannot be, you should not take this class.
• Earnestly having a tough quarter
  • I sympathize and would love to support you in other ways, but policy exceptions are not one of them.

Beyond this, the instructor will grant exceptions on a case-by-case basis given enough prior notice. Email the instructor to discuss your situation. Just requesting an exception does not grant it – the instructor must confirm, and so giving yourself as much lead time as possible is helpful here.

If notified within the first week of the quarter and with your undergrad advisor cc’ed on the email, the following are potentially valid reasons for exceptions:

• Scheduled family-related engagements like birthdays, weddings or graduations
• Religious observances and holidays
• Chronic illness – that is, something about the way your body or mind works that interferes with your ability to turn work in on time

If notified more than 24 hours before the due date and with your undergrad advisor cc’ed on the email, the following are potentially valid reasons for exceptions:

• Death or sudden need for support of a family member
• Legal appointments or court dates (immigration issues, family law, etc)
• Housing insecurity (facing eviction, issues with short-term housing, etc)

The instructor will not grant exceptions requested within 24 hours of the assignment due date or exam date, unless your situation is a life-altering crisis. If illness or other circumstances prevented you from notifying the instructor in advance, and this has sufficiently affected your grade, your best option is discussing the situation with your undergraduate advisor and having them reach out to the instructor.

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 anonymous feedback or contacting the Office of the Ombud.