CPSC 421-010 Object-Oriented Programming Spring 2025

Archive

• Post Midterm Exam Posted: Mar 12

  Work Due on Wednesday, Mar 12 by 4:30 pm. See Class Meeting 15 for more details.

  • Exercise 48: Lambda Functions Crossword
  • Exercise 49: Convert II Delayed until after the next class meeting
  • Exercise 50: IoC Crossword
  • Exercise 51: RAII Crossword
• Midterm Posted: Mar 11

  Midterm Exam Today, Tuesday, Mar 11

  • In our regular classroom
  • Paper is provided and no computer needed
  • I am in Flagstaff, Arizona, on Mar 10-11 for the 2025 NSF CIRC & CNS MRI PI Meeting. My RA, Mr. Kyle Rossi, along with my TA, Ms. Afia Asante, will proctor the Midterm Exam.

  • My Office and Advising Hours are cancelled on Mar 11.

  • Work Due on Wednesday, Mar 12 by 4:30 pm. See Class Meeting 15 for more details.

    • Exercise 48: Lambda Functions Crossword
    • Exercise 49: Convert II Delayed until after the next class meeting
    • Exercise 50: IoC Crossword
    • Exercise 51: RAII Crossword

• Week 8 Class 15 Thu Mar 06 Posted: Mar 06

  After Class

  • Project 2

    I graded and provided feedback on the two diagrams from Project 2. The scores are available in Brightspace, with each out of 10 points. Since you are responsible for both diagrams on the Midterm Exam, I highly recommend reviewing the feedback.

    • Class Diagram Feedback can be found in GitHub issues labeled v2class.
    • Sequence Diagram Feedback is in Brightspace with the grade.

  Announcements

  • Midterm Exam Tuesday, Mar 11
  • Out of Town Mar 10-11. Office and Advising Hours are cancelled on Mar 11. Mr. Kyle Rossi will proctor the exam.
  • After Class Be alert to postings in the After Class.
  • Project 2 Diagrams Not sure how much of Project 2 I will be able to grade before the Midterm. However, I will definitely give you feedback on your diagrams. So watch for those scores and feedback. I will post a notice in the After Class.
  • Exercise Due Date

  Agenda

  • Notes: Lambda Functions
  • Exercise 48: Lambda Functions Crossword

  • Exercise 49: Convert II

    Note: Decided to delay this until our next class meeting after the Midterm Exam

    Following my example in class, mark the concerns and rearrange the code to rearrange the concerns in the file.

    Convert010

  • Notes: IoC
  • Exercise 50: IoC Crossword
  • Notes: RAII
  • Exercise 51: RAII Crossword

  Unless otherwise noted, exercises are due by 4:30 pm on Wednesday, Mar 12 (day after Midterm)

• Week 8 Class 14 Tue Mar 04 Posted: Mar 04

  Announcements

  • After Class
  • Midterm Exam

  • Out of Town

    I will be in Raleigh, North Carolina, on Mar 10-11 for the 2025 NSF CIRC & CNS MRI PI Meeting. This is required as a PI (Principal Investigator) on an NSF grant.

    My RA, Mr. Kyle Rossi, along with my TAs, will proctor the Midterm Exam.

    My Office and Advising Hours are cancelled on Tue, Mar 11.

  Agenda

  • Notes: Callbacks
  • Exercise 44: Callbacks Crossword

  • Exercise 45: Sorts

    For each @TODO:

    • Uncomment the std::sort() call and test
    • Write a predicate function appropriate to the sort directly in sorts.cpp
    • Pass the predicate function for the comparison argument

    Rules:

    • No templates
    • No function objects (functors)
    • No additional files

    GitHub Invitation link in Brightspace.

    Implement at least 1 @TODO by Wednesday. The rest are due on Friday.

  • Exercise 46: Convert

    Following my example in class, first mark the current concerns. Then, rearrange the concerns in the file to separate them.

    Convert010

    GitHub Invitation link in Brightspace.

  • Notes: UML Multiplicity
  • Exercise 47: UML Multiplicity Crossword
  • Notes: Lambda Functions

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Mar 05

• Midterm Exam Posted: Mar 04

  The Midterm Exam is during class time in our regular classroom on Tuesday, Mar 11.

  You are responsible for the following:

  • Software Design - Definition, the two types of design (so far), where they come from, what they are concerned with
  • Software Design Characteristics - Know the list of characteristics
  • Algorithmic Decomposition - Definition and how it works
  • Structure Diagram Given code or description, draw.
  • Coding Style Given a function declaration or definition, improve the code using the principles we discussed in class. This includes proper parameter passing.
  • Function Design Given a description, create a function declaration with a proper Doxygen-style comment. Parameter passing must follow the coding-style rules.
  • Generalizing Functions - Given an example function, show how to generalize it
  • Physical Organization - Include guards, header comments, function comments, and separate function declarations and definitions
  • Naming & Method Naming Standards - Given a list of names, correct the poor names
  • Iterator - Four basic operations in GoF terms and C/C++ operators
  • Free-Function Stereotypes - Know the terms and be able to write a free function for each stereotype
  • Concerns - Definition, separation of concerns, be able to identify concerns
  • UML Sequence Diagram Given a scenario, be able to draw a sequence diagram
  • XML Know what is and what is not an XML concern
  • UML Class Diagram - C++ code ⇨ diagram, diagram ⇨ C++ code, single class only (no relationships)
  • Organizing Functions - free functions in a file, in a namespace, and as static methods of a class
  • Cohesion - Definition
  • Encapsulation and Information Hiding - Definition of each, the encapsulation rule and the information hiding rules.
  • Member Initialization List - Order of field creation, proper use of member initialization list

  Note that Method Stereotypes and Callbacks are not on the exam.

  The exam has assorted problem types, including short answers, definitions, comparisons, drawing diagrams, and coding.

  The questions are based on what I covered in class, including the exercises and projects. If I did not cover it in class, it is not on the exam.

• Week 7 Class 13 Thu Feb 27 Posted: Feb 27

  After Class

  • Exercise 43: Member Initialization List Mistake in the CMakeLists.txt file for the Image directory. It refers to:

    It should be:

    You can make (and commit) this change. If you have problems, let me know and I can do it for you.

    Note that depending on your platform (and file system), it might not be a problem.

  • Exercise 43: Member Initialization List The Bank problem is really a compiler warning, not a compiler error. However, it is more complicated than that. While clang issues a warning, gcc does not. Here is the clang warning:

    Fix this using member initialization lists. Do not use this-> to fix.

  Announcements

  • Guide: Installing srcml

  Agenda

  • Notes: Encapsulation
  • Exercise 41: Encapsulation Crossword
  • Notes: Constructors and Initialization
  • Exercise 42: Constructors and Initialization Crossword

  • Exercise 43: Member Initialization List

    Fix the code with the following problems in the following order:

    1. Sensor - compiler error
    2. Bank - compiler error
    3. Temperatures - compiler error
    4. Image - compiler error
    5. Image - implement @TODO

    Do not:

    • Rename any variables, parameters, or fields/data members
    • Change the type of anything
    • Add any comments
    • Add any methods, functionality, etc.

    Perform each change in a separate commit

    The GitHub Classroom link is in Brightspace.

    Note: Normally, each these programs would each be in a separate Git repository. We only have them in one repository as four separate invitation links is a bit excessive.

  • Notes: Callbacks
  • Exercise 44: Callbacks Crossword Due after next class

  Unless otherwise noted, exercises are due by 4:30 pm on Mon Mar 4

• Week 7 Class 12 Tue Feb 25 Posted: Feb 25

  Announcements

  • Office Hours Adding 10:30 - 11:30 today to my Office Hours (normally Advising Hours)

  • Project 1 Scores Project 1 scores for parts v1a - v1e are posted.

    I changed how the scores are presented. The grade item Project 1 has the overall score, out of 100 points (parts v1a, v1b, v1c, v1d, and v1e). In addition, the individual part scores are reported in separated grade entries, e.g., Project 1 v1a.

  • Project 2 Added due dates

  • Excercise 33: Utilities II

    Extended due date: 4:30 pm on Wed Feb 26

    Note that if you don't have a 0 or 10/10, that to get points you must make commits and fix your code.

  • srcml on macOS I have an experimental brew package for the srcml client on macOS. With brew installed:

    To verify if srcml is installed:

    You can run this, from the build directory, on a source-code file and then run with srcfacts:

    Or, direct entry of text:

  Agenda

  • Exercise 37: Iterator Crossword
  • Notes: Cohesion
  • Exercise 38: Cohesion Crossword

  • Demo: Cohesive Declarations

    Cohesive Declaration

  • Exercise 39: Cohesive Declarations

    Perform the commits for each choice of ordering declarations.

  • Notes: Method Stereotypes
  • Exercise 40: Method Stereotypes Crossword
  • Notes: Encapsulation

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Feb 26

• Week 6 Class 11 Thu Feb 20 Posted: Feb 20

  After Class

  • Project 1 Scores

    Project 1 scores for all parts are posted.

    I changed how the scores are presented. The grade item Project 1 has the overall score, now out of 100 points (parts v1a, v1b, v1c, v1d, and v1e). In addition, the individual part scores are reported in separated grade entries:

    • Project 1 v1a
    • Project 1 v1b
    • Project 1 v1c
    • Project 1 v1d
    • Project 1 v1e

  • Exercise 30: Utilities

    Scores are in Brightspace.

    See the note below on what I took off points for.

  • Underlining for yuml.me Class Diagrams

      [StaticClass|__+flag:Boolean__ |__static()__ ]
    

  • srcml on macOS I have an experimental brew package for the srcml client on macOS. If you are on macOS, let me know if it does or does not work. With brew installed:

    To verify if srcml is installed:

    You can run this, from the build directory, on a source-code file and then run with srcfacts:

    Or, direct entry of text:

  Announcements

  • Project 2

    • All issues for v1d and v1e are in GitHub. I have not updated the scores in Brightspace.
    • I adjusted the due dates for Project 2

    • v1e Issue: Unnecessary added XML parsing code

      The purpose of v1e was to show how the new design makes adding functionality easier. Unfortunately, some implementations added low-level parsing code that was not necessary, and, in many cases, broke the parsing, especially with the BIGDATA.

      At most for each added count you needed:

      • One counting variable
      • One boolean variable to keep track if you were in the proper element (see next item)
      • Detect the start tag name and set the boolean variable (see next item)
      • Detect the attribute while in the start tag name and update the counter
      • Add the line to the output

      You are not writing XML parsing code. I already did that. You are redesigning the code.

    • v1e Issue: Code assumes unique attribute and value

      The code that counts the number of line comments assumes that the comment element is the only element that has the form: <… type="line">

      While not verified, it is also probably the case that the code for counting the number of literal strings has the same limitation.

      These elements do have these forms. But assuming this is true for all other srcML elements, current or future, is an assumption that is never stated or described. The choice is to describe in excruciating detail why this is the case, how someone could detect it, and what to do with their data when this happens. This requires forms that have to go to legal and be filled out in triplicate.

      Another choice is to fix the problem.

      I will not take points off for this issue. However, I expect it to be fixed:

      • It is easy to make assumptions about our input data for programming ease or program optimization
      • All assumptions must be clearly defined
      • A better choice is to remove the assumption
      • It is often easier (and better) to remove the assumption than it is to work around it
      • So if you can remove the assumption without much effort, it will pay to do so
      • There are exceptions as dealing with uncommon usages may delay delivery for common usages

  • Project 2 Pull Request Added a Project 2 pull request that will add the files XMLParser.hpp and XMLParser.cpp and modify CMakeLists.txt so that XMLParser.cpp is part of the build.

  • Exercise 30: Utilities

    I am still finishing the scoring. Points are taken off for:

    • @TODOs that are incomplete or not completed
    • Doxygen comments that are missing, incomplete, or contain errors
    • Scalar values passed by const value, e.g., const int
    • Objects passed by value instead of const reference, e.g., std::vector<int> v
    • Poor naming

    Notes: Utilities Feedback

  • Zero-Tolerance Policy

    The following are fundamental design choices at the C++ level that we have spent more than enough time on. To make sure the message is received, any violations of the following will receive a 0 on the exercise, project, or test question:

    • Passing std::string by value, e.g. void f(std::string);
    • Passing std::vector<> by value, e.g., void f(std::vector<int>);
    • Passing by const value, e.g., void f(const int n);

    For why we do not pass large objects by value, see the Benchmarks

  Agenda

  • Exercise 33: Utilities II

    If you received a non-zero score for Exercise 30: Utilities, your score on that exercise will be replaced by this score if this score is higher. So if you got a 7/10 on Exercise 30, and you get a 10/10 for Exercise 33, your Exercise 30 score will change to a 10/10.

    Using the feedback in class, improve your function declarations for the Utilities code. I suggest a commit for each change of a function name, e.g., Rename ..., and each change of a parameter type, e.g., Change ....

    Other changes to consider:

    • Make sure to correctly identify [in],[out], and [in/out]. I saw some [in/out] that is really [out]. If the previous contents of a parameter are not used in the function, and the parameter value is changed, it is an [out].
    • You can pass data out from a function via a parameter or the return value. Do not use both for the same data.
  • Guide: Boolean Expressions
  • Notes: Iterator
  • Notes: UML Class Diagrams
  • Exercise 35: UML Class Diagrams Crossword

  • Exercise 36: Create a UML Class Diagram

    Create a UML Class Diagram at yuml.me for the class diagram on the right.

    Compose your class diagram at yuml.me. The resulting contents of the box on yuml.me will go into the file ClassDiagram.txt in the GitHub Classroom Repository (link in Brightspace). You should be able to copy the contents of the file ClassDiagram.txt and paste it into the editor at yuml.me and see the diagram on the right.

    Your final result should look exactly like the image shown here. The style used for the image is Boring, instead of the default Scruffy or Plain.

    Make sure to commit after each of the following parts:

    • Name of the class
    • Attributes
    • Operations

    Note that yuml.me can be temperamental. Add iteratively and carefully. Commit often, as you might find yourself breaking your previously working diagram.

    

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Feb 24.

• Week 5 Class 10 Thu Feb 13 Posted: Feb 13

  After Class

  • President's Day Observance Tuesday, Feb 18 University open, no classes

  • Due Dates Exercises due next week ordered by due date:

    • ✓ Exercise 29: Scope Crossword Due: Monday, Feb 17
    • ✓ Exercise 31: Grouping Functions Crossword Due: Monday, Feb 17
    • ✓ Exercise 32: Sequence Diagram Due: Tuesday, Feb 18
    • Exercise 30: Utilities Due: Wednesday, Feb 19

    Each exercise is due by 4:30 pm on the day indicated.

  • Exercise 30: Utilities

    For each @TODO you are to declare a single function declaration, and only call it once in the example. Do not solve any of the @TODOs with two or more functions, or call the function more than once.

  Announcements

  • Project 2

    I am introducing Project 2 because we do not have class on Tuesday, Feb 18.

  Agenda

  • Notes: Scope
  • Exercise 29: Scope Crossword Due: Monday, Feb 17

  • Exercise 30: Utilities Due: Wednesday, Feb 19

    Provide a single function declaration in the file Utilities.hpp and a single function call in UtilitiesExamples.cpp for each @TODO in UtilitiesExamples.cpp. Once you do, remove the @TODO for that block. The function declarations in Utilities.hpp must follow the order of the examples of the call in UtilitiesExamples.cpp.

    Do not implement the function. Do not provide a function definition. Only provide the declaration and example single call using the variables given. The function declaration must be complete enough so that it would be possible to implement the function.

    Make sure the program compiles. But, since you are not providing a function definition, the program will not link or run successfully.

    To compile the program without linking:

    For each function declaration, include a Doxygen comment that describes the function and describes what data is IN, OUT, or IN/OUT. An example is already in the include file. Note that Doxygen comments start with /**.

    Finish the problem for each @TODO, remove the @TODO, and then commit. Each commit should complete one @TODO. The first one is completed as an example.

    If any of the following occur, then the entire exercise score is a 0:

    • Function definitions
    • Does not compile (expected to not link)
    • Object files, e.g., UtilitiesExamples.o, in the repository
    • Additional includes
    • Any code changes besides adding function declarations and implementing @TODOs
    • Use of any other files
    • Use of C++ standard library functions
    • Use of templates
  • Notes: Grouping Functions
  • Exercise 31: Grouping Functions Crossword Due: Monday, Feb 17
  • Notes: Sequence Diagrams

  • Exercise 32: Sequence Diagram Due: Tuesday, Feb 18

    Create a sequence diagram at SequenceDiagram.org for the diagram on the right, which is for parsing a start tag with an attribute.

    Start with the SVG file with the GitHub Classroom Repository link at Brightspace, and commit your changes to that repository.

    Your final result should look exactly like the image shown here.

    Make sure to save as a SVG Image File (vector image with embedded source text)

    

  Each exercise is due by 4:30 pm on the day indicated.

• Project 2 Posted: Feb 13

  Continue to improve the design of srcFacts using more language features. There are no changes to the functionality of this project, only to the design.

  In addition to the following code changes, you will maintain two modeling diagrams. There will be a pull request to add the starting files to your repository.

  • A UML Sequence Diagram, SequenceDiagram.svg, to model the relationship and control between srcfacts.cpp, the xml_parser functions, and the class XMLParser. In particular, you must show the same function/method calls used for each part. The sequence diagram for the sequence diagram is at sequencediagram.org. Make sure to export and save it as SVG.
  • A UML Class Diagram, ClassDiagram.txt, to model the class you create. This means showing the UML form of all fields/data members and member functions. The format for the diagram class diagram is the text yuml.me format.

  The diagrams must be updated to reflect the code for each tag. So do not tag until the part below is done and any diagrams are updated.

  Tag v2a Implement and close all issues I created as feedback from Project 1. When you finish fixing an issue, at least one commit must describe what you are changing. Add your calls' exact function names and (UML form of) parameters to the xml_parser for the sequence diagram. Due Feb 20 24

  Tag v2b Create a namespace, xml_parser, for the functions in xml_parser. This will involve making changes to the files srcfacts.cpp, xml_parser.hpp, and xml_parser.cpp. Due Feb 21 24

  From now on, do not change the files xml_parser.hpp or xml_parser.cpp.

  Tag v2c Create the class XMLParser in the files XMLParser.hpp and XMLParser.cpp where the methods call the free functions from xml_parser.hpp. Do not use any fields/data members. The method parameters must be identical to the parameters of the free functions in xml_parser.hpp. Add the XMLParser as a participant for the sequence diagram and show how it is involved between srcFacts and xml_parser. Due Mar 4

  Tag v2d Eliminate any parameters in the XMLParser methods that you can, replacing them with field/data members in the class. In other words, move as many XML parsing variables from srcfacts.cpp as possible. Do this one field/data member at a time. For the class diagram, show the added fields and the removal of parameters. For the sequence diagram, update the parameter lists of the calls to the XMLParser. Due Mar 5

  Tag v2e Inline the calls to the xml_parser free functions into your XMLParser methods. Inlining the calls does not mean adding the inline specifier, and it does not mean changing anything in XMLParser.hpp. Do this one free function call at a time. Ultimately, your XMLParser.cpp should have no calls to xml_parser functions and will not need to include xml_parser.hpp. Do not make any changes to the files xml_parser.{hpp,cpp}. For the sequence diagram, remove the xml_parser participant and any calls. Due Mar 6

  Ensure the project compiles, builds, and produces the correct answer at every commit with GCC and Clang.

  There is a zero-tolerance policy for the following. A zero-tolerance policy means that you will receive a zero for that part if any of the following are violated:

  • At every tag, v2a, v2b, v2c, v2d, and v2e, the program must compile and build in gcc and clang without errors or warnings.
  • All data members/fields must be private
  • No mention of srcML or use of specific srcML element names (or attribute names/types) in the files XMLParser.hpp, XMLParser.cpp, xml_parser.hpp, or xml_parser.cpp.

• Week 5 Class 9 Tue Feb 11 Posted: Feb 11

  After Class

  • The BUILD.md file contains instructions on turning TRACE on and off

  Announcements

  • Project 1
    • v1b Scores were added to Brightspace

    • v1c Issues posted in GitHub. Scores will be added to Brightspace later.

      Issues include:

      • Coding Practices Task List issue is still open
      • Missing n const
      • Missing n auto
      • Function comment does not follow style
      • Mention of srcfacts in refillContent files
      • Missing header comment in refillContent.hpp
      • Missing newline at EOF in refillContent.{hpp,cpp}
      • Missing success return
      • Mixed tab and space indentation
      • Multiple blank lines
      • Return in separate section for srcfacts.cpp
      • Unneeded include files in refillContent.hpp
      • Header comment in refillContent.{hpp,cpp} should not include the function comment
      • Include file refillContent.hpp is not self sufficient with clang
      • Insert blank line after filename in header comment in refillContent.{hpp,cpp}
      • Function declarations missing comments in refillContent.hpp
      • Function definitions missing comments in refillContent.cpp
      • Missing filename in header comment in refillContent.{hpp,cpp}

      I have some more feedback on the contents of comments, but they will not affect your score.

    • v1d and v1e Due dates extended.
    • Every function should have single purpose. Do not make a function try to be an Accessor::predicate and Mutator::command. Use separate functions for each.
    • If your xml_parser functions refer to srcML, srcFacts, or srcfacts concerns, then they violate the rule of none of these concerns in xml_parser. Specifically, if they contain expression counts or use srcML tags, such as "expr", then they violate a primary design rule for this project. Remove them immediately.
  • Exercise 24: srcFacts Concerns Answers

  Agenda

  • Notes: Naming
  • Exercise 26: Naming Crossword

  • Notes: Method Naming Standards

    We will follow these naming standards in this course.

  • Exercise 27: Method Naming Standards Crossword

  • Exercise 28: TRACE

    Demonstrate the running of your program with TRACE on for a:

    • line comment
    • short block comment
    • Doxygen block comment

    You will have to create the srcML for each of these code examples. Use the srcML Playground. Keep the examples as short as possible (i.e., only include a comment). Download these files and have them ready before you start the screencast. Also before the screencast, build with the TRACE option on.

    The form to submit the asciinema link is in the title of this exercise.

    To make the output cleaner, redirect the generate table to a file ./srcfacts < FILENAME > report.md

  • Notes: Event State
  • Notes: Scope

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Feb 12

• Week 4 Class 8 Thu Feb 06 Posted: Feb 06

  Announcements

  • Project 1 Pull request for xml_parser, as used in part v1d, is in your repository. It adds the (empty) files xml_parser.hpp and xml_parser.cpp. It also updates the build so that xml_parser.cpp is compiled.
  • General Note If I state there is a pull request, a branch, or a report, and you do not see it in your repository, then check in the GitHub Repository (not GitHub Codespaces). If you do not see it, let me know. Creating these for the whole class is a bit unreliable and sometimes a repository may be skipped.

  • Project 1 v1b

    Feedback for Project 1 v1b is posted as issues in your GitHub repository. If you had a v1c tag, I used that version for any style issues. The only thing I specifically used the v1b version was to build and run the project. No scores yet. Issues include:

    • Unneeded include files in srcfacts.cpp
    • Deleted details of function comment in refillContent.hpp
    • Deleted details of function comment in refillContent.cpp
    • Incorrect include guard name
    • Invalid header comment for refillContent.hpp
    • Invalid header comment for refillContent.cpp
    • Unneeded include files in refillContent.hpp
    • Parameter name deleted from refillContent
    • Missing nodiscard attribute from refillContent
    • Unneeded include files in refillContent.cpp
    • Function comment with no function
    • Mention of srcFacts in refillContent files
    • xmlNameMask is not part of refillContent
    • Unnecessary use of the extern specifier
    • Inconsistent include guard name

  • Project 1 v1d

    • Cannot change the output. Design change must avoid breaking the program (build or runtime results) at all costs.
    • Direction of parameters: Algorithmic Decomposition
    • XML Interface Concepts: XML
    • Accessor::Predicate Stereotype: Free-Function Stereotypes
    • Accessor::Predicate Stereotype Example: Free-Function Stereotypes
  • Increment Quiz Results

  • In-Class Exercises Failure to provide both name and email on an in-class exercise will lead to an immediate 0.

    No, I do not want your student ID number.

  Agenda

  • Notes: Concerns
  • Exercise 23: Concerns Crossword
  • Exercise 24: srcFacts Concerns Quiz
  • Notes: Vertical Development
  • Exercise 25: Vertical Development Crossword

  • Exercise 22: Rainfall V

    This exercise is optional. Commits are already in OOPS25-Rainfall-010.

    Make the same commits in your repository.

  • Notes: Generalizing Functions

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Feb 10

• Week 4 Class 7 Tue Feb 04 Posted: Feb 04

  After Class

  • Project 1 Pull request for xml_parser, as used in part v1d, is in your repository. It adds the (empty) files xml_parser.hpp and xml_parser.cpp. It also updates the build so that xml_parser.cpp is compiled.
  • General Note If I state there is a pull request, a branch, or a report, and you do not see it in your repository, then check in the GitHub Repository (not GitHub Codespaces). If you do not see it, let me know. Creating these for the whole class is a bit unreliable and sometimes a repository may be skipped.

  Announcements

  • Project 1

    • Posted due dates for parts v1d and v1e
    • No scores/feedback for v1b. I will wait until after v1c.
  • Exercise 18: Rainfall V Report5.md in the feedback branch, scores in Brightspace.
  • Guide: srcML Guide to using srcML

  Agenda

  • Notes: Free Function Stereotypes
  • Exercise 19: Free Function Stereotypes Crossword
  • Exercise 20: Increment Quiz
  • Guide: Coding Standard
  • Exercise 21: Coding Standard Crossword
  • Notes: Concerns

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Feb 05

• Week 3 Class 6 Thu Jan 30 Posted: Jan 30

  After Class

  • I made changes in Brightspace for viewing grades. It now should show the points, e.g., 10 / 10 for a crossword, instead of the overall weighted grade. It should display it this way on the Project also.

  Announcements

  • Project 1 v1a

    Scores (out of 20 possible) are in Brightspace for Project 1. The feedback is in GitHub in the Issues tab of your repository. Issues include:

    • Missing tag v1a
    • Inconsistent spacing
    • Missing changes for tag v1a
    • Inconsistent spacing around keywords
    • Declaration does not match existing code
    • Inconsistent variable name returncount
    • Inconsistent spacing around operators
    • Inconsistent return statement count label
    • Code at tag v1a does not build

    Do not expect that every part (e.g., v1b, etc.) will be graded before the next part is due. This is a straightforward part. The rest of the parts involve a lot more coding. Also, for some parts, I want to grade the parts together.

    The first step of Project 2 will be to fix these issues. You can fix these issues now or later. For small changes, I suggest now. Use a commit message that starts with "Fix". After the issue is fixed, close the issue.

  • Project 1 v1c

    Added the due date for v1c.

    The Coding Practices Task List is an issue in your GitHub repository.

  • Exercise 5: Rainfall II and Exercise 13: Rainfall III Feedback in Report23.md in the feedback main branch, scores in Brightspace.
  • Exercise 13: Header File Quiz Posted your filled-out quiz as an Assignment

  Agenda

  • Notes: XML

    You will not be asked to explain or define any XML terminology as part of any exam. However, to discuss the problem domain of the project, we require this terminology.

    You will need to understand that the parts of XML are a concern, and also that the implementation of a parser for XML is another concern. We will cover the idea of a concern later on.

  • Exercise 16: XML Crossword
  • Notes: Coding Style
  • Exercise 17: Coding Style Crossword
  • Notes: Rainfall Coding Practices

  • Exercise 18: Rainfall V

    Continuing on using the workflow from Rainfall I

    As before, you can follow along and see the commits that I make in class:

    OOPS25-Rainfall-010

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Feb 3.

• Week 3 Class 5 Tue Jan 28 Posted: Jan 28

  After Class

  • Corrected exercise numbering

  Announcements

  • Engineering, Engineering Technology, and Computing Spring 2025 Career Fair

    

    Career Fair Registration
    Registration will close on January 31, 2025, at 11:55 pm
    Date: Tuesday, February 11, 2025
    Time: 10:00 am - 2:00 pm – NOTE THE NEW END TIME (come and go between classes)
    Location: Jean Hower Taber Student Union Ballroom & 3rd Floor
    

    We are sold out for our Career Fair once again!
    The fair is for students interested in co-op, internship, and full-time placements.

    Career Fair & Interviewing Workshop
    Date: Tuesday, January 28, 2025, from 1 – 2:30 pm

    Resume Review Open House Three Sessions Offered:
    Date: Thursday, January 30. 2025
    

    • 10 am – 12 pm
    • 12 pm – 2 pm
    • 2 pm - 4 pm
  • Guide: gh default

  • CMake Presets - srcFacts on macOS

    On macOS, the libarchive library, libarchive.dylib, is already installed. You just need the proper include files.

    I added an (optional) pull request to the repos. If you accept this pull request in GitHub, and do a git pull in your cloned repositories, it will add a preset for macOS that will correctly set up the include files for libarchive. This does not use the libarchive from brew, but the version already installed on your machine.

    To use this, in your build directory, use cmake with the macos preset:

    • This does not change your CMakeLists.txt
    • It adds the file toolchain_macos.cmake to download the appropriate include files
    • It adds the file CMakePresets.json to add the preset macos that runs the toolchain
    • If you are on another platform it will not find the preset, and accepting this pull request will not cause any problems.

    We will have more presets as the semester goes on, for all platforms. So, be sure to start using this on macOS. To see what presets are available:

    Also, if you do not see a pull request, then you may have created your repository (using the GitHub Classroom Invitation Link) after I added the pull request. In that case, you already have the preset. Try it and see (if on macOS).

  • Exercise 5: Rainfall II and Exercise 13: Rainfall III Still grading
  • Project 1: srcFacts Check due dates

  Agenda

  • Notes: Git Basics

    With a few exceptions, the use of proper Git Commit messages is not a part of the grade for Project 1. However, you should try to follow the rules:

    • Essential for group projects
    • Good practice for real-world projects
    • A skill that takes practice
    • Allows me to monitor what students are working on and what they have completed
    • Allows me to assist you individually
  • Guide: Git Commands
  • Exercise 13: Header File Quiz
  • Notes: Separate Compilation
  • Exercise 14: Separate Compilation Crossword
  • Notes: Rainfall Coding Practices

  • Exercise 15: Rainfall IV

    Continuing on using the workflow from Rainfall I

    As before, you can follow along and see the commits that I make in class:

    OOPS25-Rainfall-010

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Jan 29

• Week 2 Class 4 Thu Jan 23 Posted: Jan 23

  After Class

  • gh default The GitHub command-line client, gh, is very useful. However, the default repo for your GitHub Classroom clones is not your own repo, but the original that your repo was cloned from, the one I setup to generate yours. So if you do a:

    it doesn't take you to your repo at GitHub, but to the repo UACPSC/cpsc-421-oop-spring-2025-srcfacts-OOPS25-srcFacts.

    The easy fix is to reset your default. The command is:

    It will ask you to pick what you want as your default. Pick your repo. Here is an example run:

    If you want to truly automate the command and not have to pick, you can use the following:

    Note that every time you clone your repository you will have to do this.

  • srcFacts on macOS

    On macOS, the libarchive library, libarchive.dylib, is already installed. You just need the proper include files.

    I added an (optional) pull request to the repos. If you accept this pull request in GitHub, and do a git pull in your cloned repositories, it will add a preset for macOS that will correctly set up the include files for libarchive. This does not use the libarchive from brew, but the version already installed on your machine.

    To use this, in your build directory, use cmake with the macos preset:

    • This does not change your CMakeLists.txt
    • It adds the file toolchain_macos.cmake to download the appropriate include files
    • It adds the file CMakePresets.json to add the preset macos that runs the toolchain
    • If you are on another platform it will not find the preset, and accepting this pull request will not cause any problems.

    We will have more presets as the semester goes on, for all platforms. So, be sure to start using this on macOS. To see what presets are available:

    Also, if you do not see a pull request, then you may have created your repository (using the GitHub Classroom Invitation Link) after I added the pull request. In that case, you already have the preset. Try it and see (if on macOS).

  Announcements

  • Teaching Assistants
  • Exercise 9: Rainfall II Feedback and grades are not ready yet.

  • Project 1: srcFacts

    All project due dates are 11:59:59 pm.

  Agenda

  • Exercise 10: Build srcFacts

    Build and run the Project 1 srcfacts program performing the following:

    • Clone the repository and move to the repo directory (Not required if you are using GitHub Codespaces or have already cloned the repository)
    • Create the build directory - If you already have a build directory, delete it first
    • Move to the build directory
    • Create the build using cmake
    • Build the project using make
    • Run the program with the demo make run
    • Run the program with the demo directly, not using make

    • Enter the following command:

    To demonstrate this, you will record a terminal session using asciinema. It records the commands you enter and the output the command produces. asciinema is already installed in the GitHub Codespaces image. You can also install asciinema on Linux/WSL/macOS.

    asciinema is relatively straightforward to use.

    You can play, pause, skip, etc. You can also copy the commands as text. Note that the replay even includes your pauses and any delay as the command is run.

    At the end of the terminal session, asciinema will show a URL. Anybody can use this URL to view the session. This is what you will submit for the exercise to the link in the exercise title.

    IMPORTANT The URL should not contain "connect" or be a local file. Test your URL in a browser verifying that it shows the session you recorded. An incorrect URL will receive a 0.

  • Notes: Algorithmic Decomposition
  • Exercise 11: Algorithmic Decomposition Crossword
  • Notes: Rainfall Coding Practices

  • Exercise 12: Rainfall III

    Continuing on using the workflow from Rainfall I

    As before, you can follow along and see the commits that I make in class:

    OOPS25-Rainfall-010

    If you have any questions or issues, make sure to contact me.

  Unless otherwise noted, exercises are due by 4:30 pm on Fri Jan 24

• Project 1: srcFacts Posted: Jan 23

  One approach to understanding a system's source code is to count things, such as the number of statements, functions, classes, expressions, and LOC (Lines Of Code). The program srcfacts produces a report of these counts.

  Writing code in a program to directly parse C++, i.e., identify the syntactic parts of the code, is very difficult. So, the srcfacts program does not parse the C++ source code. It uses another tool, srcML, to convert the C++ source code into an XML format. The srcfacts program inputs this XML format, parses the XML while collecting counts of parts of the input code, and produces the report. The input has to be in the srcML format, e.g., demo.xml, however it can be compressed or part of an archive, e.g., demo.xml.zip, linux.xml.gz.

  The srcfacts.cpp program is one large, main() function using almost no design features. It is extremely fast; for example, it can produce a report on the entire Linux kernel (verison 6.13, 60,392 source-code files, an 4.7 GB file in the srcML format) in under 8 seconds. However, in its current form, it is not easy to debug the XML parsing, add additional program element counts, or even understand what is going on. It includes code for parsing all parts of XML, but it would not be easy to adapt the XML parsing code for another purpose, e.g., another report. The only way to reuse this code is by copy/paste reuse. Overall, it has the following:

  Design Characteristic	Level
  Scalability	Very High
  Performance	Very High
  Portability	Medium
  Usability	Medium
  Modularity	Very Low
  Extensibility	None
  Reusability	None
  Maintainability	None

  Your task is to take the srcfacts code, improve the overall design, and extract the XML parsing part of the code. When completed, a set of functions in the files xml_parser.hpp and xml_parser.cpp will handle as much XML parsing as possible, while the main program, srcfacts.cpp, generates the report using the XML parser functions for parsing.

  • You do not have to understand how to parse XML. You are only repackaging XML parsing code, not writing from scratch.
  • The existing code is brittle, so you need to work carefully not to break the code
  • The repository includes example input
  • Keep in mind all aspects of design as we discuss them in class

  The steps (in order) with the associated (git) tag are:

  Tag v1a: Without changing the design, add the code necessary for the report to include the number of return statements. First see how the other counts are collected, then use it as a guide. Do not make any other changes to the project. The heading in the table must be "Returns". Due Jan 28

  Tag v1b: Move the refillContent() function into the separate refillContent.hpp and refillContent.cpp files. The build is already configured for these files. Due Jan 31

  Tag v1c: Apply the specific design changes from the Coding Practices Task List (an issue in your repository). As you verify that the code follows the practices given, check them off. Once you have completed all of them, close the issue. Due Feb 4

  Tag v1d: Extract a set of (free) functions to handle the low-level details of the XML parsing. Put the declarations into xml_parser.hpp and the definitions into xml_parser.cpp. Extract one function at a time, i.e., each commit can only include a single extracted function. Due Feb 11 Feb 13

  Tag v1e: Add the necessary code to count the number of line comments and literal strings. The headings in the table must be "Line Comments" and "Strings". Due Feb 12 Feb 14

  Your repository for this project is through GitHub Classroom, with a link on the Brightspace course page.

  • Projects in this course build on each other. Failure to complete Project 1 will impede progress on Project 2.
  • Steps must be completed in order, e.g., Step v1a must be completed before Step v1b.
  • Your code must compile with both g++ and clang. An easy way to verify is with GitHub Codespaces.
  • Be sure to follow the good practices we discuss in class
  • There are no classes or structs created for this project. You are extracting a set of free functions. Any class you create to solve this problem now would not solve the primary problem of how the srcFacts code uses an XML parser.
  • The main() handles XML errors (invalid XML format) with a direct return 1; so the program exits with the status of 1. To exit the program from within any function, use exit(1); which requires the include file stdlib.h.
  • While you can create and use other branches, only the work on the main branch counts. The main branch is the default when you git clone and git checkout.
  • The code uses the library libarchive to input compressed and archive files, e.g., linux-6.6.xml.gz and demo.xml.zip. To install it on Linux, use sudo apt-get install libarchive-dev. To install it on macOS, use brew install libarchive. The GitHub Codespaces image already has libarchive-dev installed.

  General Guidelines

  • Code must compile and build
  • Do not change the existing format of the output
  • Do not add or commmit your build directory
  • Follow the programming style of the existing code. Do not change the indentation style.
  • Follow all guidelines given in class

• Week 2 Class 3 Tue Jan 21 Posted: Jan 21

  Special Announcement

  Class Meeting 3 on Tuesday, Jan. 21, is remote. We will meet via Teams during class meeting time.

  The class meeting should appear on your Teams calendar. If not, there is a direct link in Brightspace.

  Announcements

  • Office Hours Online via Teams. Contact me via chat on Teams.

  • Exercise 5: Rainfall I

    • I posted a feedback report, Report1.md, in your repository under the branch feedback. I strongly suggest looking at it on GitHub:

    • I posted the scores and any additional comments in Brightspace

    Report1.md Example report.

    Points were taken off for:

    • Differences between your code for a commit and my code in the example
    • Not following the exact format of the header comment
    • Typos in words
    • More than 2 commits
    • Wrong form of the action in the commit message. It is "Add", not "Added", "Adding", or "add".

    Also, do not use term "assignment" or "exercise" in your code. We simulate working on real code.

    If you have spacing or wording to fix, you can fix them. However, these commits must start with the word "Fix". Not "Fixing", "Fixed", or "fix", but "Fix".

  • Guides

  • Exercise 6: Development Environment Setup Results

    If you do not have cmake 3.31 or later, you will have problems with further exercises and the projects. Follow my Development Environment Setup instructions. If you have issues or problems setting it up, do not ignore it.

  Agenda

  • Notes: Software Design Characteristics
  • Exercise 7: Software Design Characteristics Crossword
  • Exercise 8: For Statement Quiz Performed during class.
  • Notes: Rainfall Coding Practices

  • Exercise 9: Rainfall II

    Continuing on using the workflow from Rainfall I

    As before, you can follow along and see the commits that I make in class:

    OOPS25-Rainfall-010

    If you have any questions or issues, make sure to contact me.

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Jan 22

• Week 1 Class 2 Thu Jan 16 Posted: Jan 16

  After Class

  • Remote Teaching In anticipation of the forecasted cold and possible extreme wind chills, class on Tuesday, Jan. 21, will be remote. We will meet via Teams.

    The class meeting should appear on your Teams calendar. If not, there is a direct link in Brightspace.

  Announcements

  • Grades for Exercises 1 & 2 are in Brightspace
  • OOP Survey Results
  • Development Environment: Tools Follow the directions in the guide to set up your development environment. Department servers have older versions of g++ and cmake, so do not rely on them.

  Agenda

  • Guide: GitHub Authentication
  • Setup for Exercise 5: Rainfall I
  • Notes: Software Design
  • Exercise 3: Software Design Crossword Due by 4:30 pm on Friday, Jan 17

  • Exercise 4: Statement Design Quiz

    • Completed during class
    • Each solution in a question produces the same result
    • Must choose the "best" choice, and state why it is better
    • If you complete the Design Quiz, you will get full credit for Exercise 4
  • Notes: Rainfall Coding Practices

  • Exercise 5: Rainfall I

    You can follow along and see the commits that I make in class:

    OOPS25-Rainfall-010

    If you have any questions or issues, make sure to contact me.

  • Exercise 6: Development Environment Setup

  Unless otherwise noted, exercises are due by Noon on Mon Jan 20

• Exercise 5: Rainfall I Posted: Jan 16

  Take the starting rainfall.cpp code and make the same changes that I make in class.

  Your code is in a repository from GitHub Classroom:

  1. Log in to your GitHub account.
  2. Click on the invitation link (GitHub Classroom Rainfall) on the main course page in Brightspace.
  3. Follow the directions to link your GitHub account to your UA ID.

  Environment

  1. Local

     This would be on your own machine with local files.

     First, you need to authenticate your local environment with GitHub: Guide: GitHub Authentication. This only has to be done once per environment, e.g. WSL on Windowws.

     Then you clone the repository. Cloning creates a local repository that is a copy of your repository at GitHub.

     You can get the repo link from the button <> Code button on GitHub, then under Local and HTTPS.

     Cloning a repository creates a directory with the name of your repository, e.g., _rainfall-_. To work on the files, you need to move into that directory:

  2. GitHub Codespaces

     GitHub Codespaces provides a development environment in the browser. When you create one from your GitHub Repository, you are already authenticated with GitHub and have a clone repository. So you can start working right away

     You can start a Codespace from the <> Code button on GitHub, then under Codespaces.

  Build Setup

  Git Workflow on Rainfall

  1. Edit files locally, e.g., add a header comment to the file rainfall.cpp
  2. Build, run, and check your work
  3. View your changes
  4. Commit current changes to the local repository:
  5. Push your local commits to the GitHub repository:
  6. View and verify your changes at GitHub in your browser Do not skip this verification
  7. View your commits locally

  Note Your code must build and compile. If you have a build warning or error, fix these before making any more changes to the code.

  Note You must commit each change that I make separately and use the exact commit message that I use in class

• Week 1 Class 1 Tue Jan 14 Posted: Jan 14

  Announcements

  • Syllabus

  • GitHub We use GitHub and GitHub Classroom in the class to manage source code for projects, exercises, and examples. You are required to have a GitHub account.

    Optionally, you can apply for the Student Github Developer Pack and get a free GitHub Pro account. To apply, your account email can be a school account, or a personal account if you upload documents to prove your current enrollment status.

  • GitHub Codespaces All exercises and projects include GitHub Codespaces as an option. It runs in and browser and offers a development environment with Visual Studio Code, along with a shell to enter commands for building (compiling and linking) and running your program. It automatically clones your GitHub repository. However, it does not automatically save your code changes back to GitHub; you must use git commands to do so.
  • Development Environment: Tools While GitHub Codespaces is great for short-term exercises, you'll want to work on long-term projects directly on your computer. Follow the instructions in the guide to set up your development environment. Department servers have older versions of g++ and cmake, so avoid relying on them.

  • O'Reilly Online Learning The course textbook is available in O'Reilly Online Learning.

    You do not have to be on the campus network (e.g., via VPN) to access O'Reilly Online Learning.

    To access content, click the "Institution not listed?" link below the dropdown and enter your UA email. You will then create an account and use that account from now on.

    For more information: Library LibGuide

  Agenda

  • Exercise 1: OOP Survey

  • Exercise 2: Course Content Crossword

    1. Fill out the crossword in your browser. Do not print and fill out on paper.
    2. Print to a PDF using the Print Button or the Print feature in your browser. Try to include the headers and footers in the PDF.
    3. Upload the PDF of the completed crossword to Brightspace in Assessments/Assignments.
  • Notes: Software Design

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Jan 15

• Welcome Posted: Dec 19

  Greetings and welcome to CPSC 421 Object-Oriented Programming (OOP) for Spring 2025.

  • Syllabus The syllabus for the course is on the main course page. It is a draft that I will finalize before our first class meeting.
  • Survey The first exercise is to fill out the class survey. The survey is due after our first class meeting, but you can complete it before.
  • Development Environment Development Environment: Tools is a guide for setting up your programming development environment for the class. It is good to start early as you will need this early in the course.

  • GitHub In the class, we use GitHub and GitHub Classroom to manage source code for projects, exercises, and examples. You are required to have a GitHub account.

    Optionally, you can apply for the Student Github Developer Pack and get a free GitHub Pro account. To apply, your account email can be a school account or a personal account if you upload documents to prove your current enrollment status.

  See you on Tuesday, Jan 14 at  9:15 - 10:30 am in (CAS) room 136