COSC-052: Computer Science II

Spring 2018

Contents

• Announcements
• Where, When, Who
• Description
• Learning Goals
• Policies
• Teaching Assistants
• Schedule
• Assignments and Grading
• Materials: Readings, Videos, and Links
• Other Interesting Links

Announcements

5/1/18: Posted the room for the final exam: ICC 115.

• C++ How to Program, Tenth Edition, by Deitel and Deitel.
• Starting out with C++, Early Objects, 7th–9th editions, by Gaddis, Walters, and Maganda.
• Data Structures and Algorithms in C++, by Goodrich, Tamassia, and Mount.

My course policies are designed to supplement the University's Undergraduate Honor System and the CS Department's Honor Policy. Unless stated otherwise when I distribute an assignment, the following is the default for all assignments for this course. I've developed my policies from past teaching experiences and from the CS Department's Honor Code at George Mason University.

I am obligated to refer all suspected cases of academic dishonesty by undergraduate students to Georgetown's Honor Council. If you have any questions about these policies or how they apply, please discuss such concerns with me during class, during office hours, or by e-mail.

In my experience, students at Georgetown do honest work. The small percentage of students who have submitted someone else's work as their own did so because they did not manage their time wisely.

Students must follow proper scholarly practice for all submitted work, whether graded or ungraded and whether a draft or final version of a proposal, paper, or program. We must acknowledge our reliance on the work of others through citation.

Students may be quite adept at and knowledgeable about citing and quoting material from traditional sources, such as books and articles. Typically, we do not have cite facts, common math formulae, or expressions of our own ideas, observations, interpretations, and analyses, However, students new to computer science may not realize that formulae, theorems, proofs, algorithms, and programs can require the same treatment as any other form of expression.

For convenience, you do not need to cite the course materials, conversations with me or information you obtain from class lectures and discussions. If you are unsure about what requires citation or what constitutes proper scholarly practice, please ask me during class, during office hours, or by e-mail.

I design my courses and assignments so students have what they need to complete the assignments individually without consulting outside resources. I determine the size of and credit for assignments based on the assumption that the work for them is the result of individual effort using only the course resources and materials. Students who use outside resources to complete assignments may not be eligible for full credit. Students who do not acknowledge their use of outside resources to complete assignments may be in violation of my course policies and the university's policies on academic integrity.

The following list details acceptable and unacceptable practices:

• You can:
  • obtain assistance in understanding course materials (textbooks, lecture notes, assignments);
  • obtain assistance in learning to use the computing facilities;
  • obtain assistance in learning to use special features of a programming language's implementation;
  • obtain assistance in determining the syntactic correctness of a particular programming language statement or construct;
  • obtain an explanation of a particular syntactic error;
  • obtain explanations of compilation or run-time error messages.
• You can obtain assistance only from me and the teaching assistants:
  • in designing the data structures and algorithms used in your solution;
  • in modifying the design of an algorithm or data structure determined to be faulty;
  • in implementing your algorithm or data structure in a programming language;
  • in correcting a faulty implementation of your algorithm or data structure;
  • in determining the semantic correctness of your program;
  • in designing an experimental study and interpreting its results.
• You can not:
  • show or give a copy of your work in any amount or form to another student;
  • see or receive a copy of someone else's work in any amount or form;
  • attempt to gain access to files other than your own or those that I designate and authorize;
  • attempt to reverse engineer routines for automatic grading;
  • inspect or retain in your possession another student's work, whether it was given to you by another student, it was found after other student discarded his or her work, or it accidentally came into your possession;
  • collaborate in any way with someone else in the design, implementation, or logical revision of an algorithm;
  • use or present as your own any algorithm, data structure, or implementation that is not of your own or of my design, or that is not part of the course materials.
  • incorporate code written by others (such as can be found on the Internet).

Policies dealing logistics:

• You have permission to occasionally take digital photos of the material on the board for your personal use, but you can not post these recordings on the Internet. It is important to understand that all of the course material is covered by copyright, either mine or someone else's.
• You should submit all assignments on time. For late projects, there will be a 1% deduction for each minute after the deadline. In the real world, it won't be your grade that decreases. It'll be your stock price.
• I grant extensions only to students who have documentation for a medical issue, a family emergency, or an accommodation from the Academic Resource Center. In the cases of a medical issue or a family emergency, it would be best to coordinate with your advising dean since these situations often affect your work in all of your classes.
• If you use your laptop for development, you should keep a backup of your projects on a university or department machine (e.g., cs-class) so I can verify that you completed the work for an assignment before the deadline.
• You must take the final exam with the section and during the period designated by the Registrar.
• It is my job to maintain a constructive learning environment for everyone. Please silence your cell phone and other electronic devices.
• If you must miss class, be sure to get the lecture notes from a classmate.
• It is fine if you must leave class early, arrive late, or leave the room to answer your phone, but you should do so in a manner that does not disturb your fellow students.
• In the case of inclement weather that results in the university's closure, we will meet virtually during normal class times using Zoom.

Name	NetID	Operating Systems	IDEs and command-line tools
Benjamin Maltbie	bm926	MacOS	Xcode, Eclipse, vi, FileZilla
Christian Collier	chc46	MacOS	Xcode, Eclipse, FileZilla
Clarissa Somers	cs1407	MacOS	Xcode, vi, sublime, FileZilla
Daniel Crosson	dfc29	MacOS	Xcode, Eclipse, make, sftp and scp
Eibhlin Goggins	esg41
Garrett Hinck	gah49	MacOS	Xcode, FileZilla
Isabella Schwartz	is392	MacOS	Xcode, Eclipse, sublime, FileZilla
Jonathan Gibson	jeg263	MacOS	Xcode, FileZilla
Josh Rosson	jnr41	MacOS	Xcode, Eclipse, FileZilla
Jake Mitchell	jpm362
Mark Ozdemir	mo732
Noah Levesque	nbl12	MacOS, Windows	Xcode, Eclipse, vi, FileZilla
Paulina Calderon	pac84	MacOS	Xcode, Eclipse, sublime, FileZilla
Parth Patel	pbp25	MacOS	Xcode, Visual Studio, FileZilla
Sarah A. Ciresi	sac282	MacOS, Linux (cs-class or other)	Xcode, Eclipse, emacs, sublime, FileZilla
Elly Meng	sm3008
Sam Thacher	smt76
Sean Letendre	srl61	Windows, Linux (cs-class or other)	vi, sublime, make, valgrind
Shoya Yoshida	sy519	Windows	Visual Studio, sublime, make, valgrind, FileZilla
Zachary Scherer	zs137	MacOS	Eclipse

• Programming Projects, 40%
• Project 1, assigned W 1/10, due F 2/2 @ 5 PM, 6 points
• Project 2, assigned W 1/31, due F 2/23 @ 5 PM, 6 points
• Project 3, assigned F 2/23, due W 3/28 @ 11:59 PM T 4/3 @ 9 PM, 8 points
• Project 4, assigned W 3/28, due R 4/19 @ 5 PM, 10 points
• Project 5, assigned W 4/18, due M 4/30 @ 11:59 PM, 10 points
• Midterm Exam, W 2/28, 20%
• Final Exam, T 5/8 4–6 PM, ICC 115, 30%
• Homework (10%)
• Homework 1, assigned W 1/10, due M 1/22 W 1/24 @ 5 PM, 3 points
• Homework 2, assigned M 1/22, due F 2/9 @ 5 PM, 5 points

String Grades::getLetterGrade()
{
  if (grade >= 94)
    return "A";
  else if (grade >= 90)
    return "A-";
  else if (grade >= 87)
    return "B+";
  else if (grade >= 84)
    return "B";
  else if (grade >= 80)
    return "B-";
  else if (grade >= 77)
    return "C+";
  else if (grade >= 74)
    return "C";
  else if (grade >= 70)
    return "C-";
  else if (grade >= 67)
    return "D+";
  else if (grade >= 64)
    return "D";
  else
    return "F";
} // Grades::getLetterGrade

I use automatic grading routines to assign an initial grade for the projects. It is important to emphasize that the grade you obtain from Autolab is an initial grade and may not be your final grade. There are many important aspects of a program that are difficult or impossible to assess using automatic grading routines. For example, automatic grading routines can not determine if you have written proper documentation. They can not easily assess if an implementation of an operation is optimally efficient. As a consequence, I start with the initial grade you obtain from Autolab and take further deductions if necessary.

For complete implementations, I use the following distribution as a guide:

• 40%: Compiles against the autograder
• 20%: Executes without failure using the autograder
• 40%: Autograder unit tests
• 10%: Internal documentation, if required
• Purpose of classes and methods explained in documentation comments
• Purpose, range, and meaning of identifiers explained, where needed
• Complex flow of control explained
• 10%: Style and formatting
• Nested indentation for loops and conditionals
• All class, method, and function headers emphasized
• Comments set off from code
• Vertical alignment of comments, where appropriate
• White space between blocks of code (and comments)
• Mnemonic identifier names
• 80%: Algorithm and Implementation
• Correct implementation of the operations
• Proper object-oriented design and implementation
• Appropriate error checking and diagnostic messages
• Appropriate data and object types
• Correct, clean, organized output format

Notice that an implementation consisting entirely method stubs would obtain an initial grade of 60%. Such an implementation is incomplete, and would be subject to further deductions based on the effort required to implement the required operations.

In addition to the above, the following deductions may be taken if applicable:

• 20%: Does not compile on cs-class
• 1–10%: Incomplete or improper submission
• 1–5%: My effort for fixing any minor issue
• 1–5%: Inefficiently implemented routine
• 1% per minute: Late deduction

• Autolab, for submitting projects
• Piazza, for online discussions.
• Canvas, for document distribution and for submitting projects if Autolab breaks.

• cppreference.com
• cplusplus.com
• C programming.com–Your Resource for C and C++ Programming
• Google C++ Style Guide
• Book: Managing projects with GNU make, 3rd Edition, by Robert Mecklenburg. We will give you Makefiles that you can modify, but if you want to learn more, Chapters 1 and 2 are probably sufficient for this class.
• Screencast: Program Organization
• Screencast: Basic Makefiles
• Screencast: Date Class Design and Implementation
• Screencast: Makefile Magic
• Screencast: DOC comments, doxygen, and posting documentation on the Web
• YouTube Playlist: Classes
• YouTube Playlist: C++ Vectors
• YouTube Playlist: Pointers
• YouTube Playlist: Self-referential Classes
• vi Reference Card
• emacs Reference Card
• gdb Reference Card
• How to Write Doc Comments for the Javadoc Tool
• doxygen: A documentation system for C++, C, Java, and other languages
• Unix as IDE
• Xcode, Apple's free integrated development environment (IDE). Make sure you install the command-line tools.
• Eclipse, a free integrated development environment (IDE) for Linux, OS X, and Windows
• NetBeans, a free IDE for Linux, OS X, and Windows (Oh! And Solaris)
• Code::Blocks, a free IDE for Linux, OS X, and Windows
• Visual Studio Express, a free IDE for Windows
• vim, an improved vi editor for Unix, OS X, and Windows. It's usually already installed on OS X and Unix systems
• Interactive Vim Tutorial
• Useful Unix Commands
• HOWTO: Log in and transfer files to cs-class from OS X and Linux
• HOWTO: Log in and transfer files to cs-class from Windows
• HOWTO: Create and compile files under Unix
• WinSSH: a secure telnet and ftp client for Windows (educational license)
• PuTTY: a free secure telnet and ftp client for Windows
• FileZilla: a free secure ftp client for Linux, Windows, and MacOS

• The 2017 Top Programming Languages
• xkcd: Old Days
• Computer Language Benchmarks Game
• An Interview with Bjarne Stroustrup, which includes his thoughts on educating computer scientists
• Now Blooming: Digital Models
• Teach Yourself Programming in Ten Years, by Peter Norvig
• Computer Science Education: Where Are the Software
Engineers of Tomorrow?, by Dewar and Schonberg
• The 18 Mistakes that Kill Startups, by Paul Graham
• Hackers and Painters, by Paul Graham
• In the Beginning was the Command Line, by Neal Stephenson
• Bjarne: the man, the language
• The Deitel Empire
• GNU gcc, which includes g++, our C++ compiler
• Peet's
• Fast Lane
• Red Bull

Copyright © 2019 Mark Maloof. All Rights Reserved. This material may not be published, broadcast, rewritten, or redistributed.