CPSC 421 Object-Oriented Programming Spring 2026

News

---

• Week 5 Class 8 Tue Feb 10 Posted: Feb 10

  Announcements

  • Project 1 v1b Feedback for Project 1 v1b is posted as issues in your GitHub repository:

    Do not change tag v1b.

    You will need to fix these issues at some point.

  • Project 1 v1c Feedback for Project 1 v1c is posted as issues in your GitHub repository:

  • Project 1 v1d

    • If you have any srcFacts or srcML concerns in xml_parser then you are going in the completely wrong direction. In fact, what you are doing is worse than the existing code. Evidence that you are doing this is a single xml_parser function which tends to have a lot of parameters.
    • 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

  • Exercise 10a: Buffering and Exercise 10b: Software Design Characteristics Quiz.

    • Due to numbering conflict, renumbered Exercise 10: Buffering
    • Exercise 10b: Software Design Characteristics Quiz is considered a bonus. I will drop your lowest exercise score.
    • You will need to know that list of characteristics for the Midterm. I would also make sure that you know how to run a program directly.

  • Guide: srcML

  Agenda

  • Notes: Concerns
  • Exercise 26: srcFacts Concerns Quiz
  • Exercise 27: Concerns Crossword
  • Notes: Vertical Development
  • Exercise 28: Vertical Development Crossword

  • Exercise 20: Rainfall V

    OOPS26-Rainfall-020

    Make the same commits in your repository.

  • Notes: Generalizing Functions

  Unless otherwise noted, exercises are due by 3:30 pm on Wed Feb 11

• Project 1: srcFacts Posted: Jan 27

  To fix bugs and add new features to software, you have to understand the source code. One approach 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 for a C++ program.

  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.18.7, 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 30

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

  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 9

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

  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. See BUILD.md for details.

  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. E.g., do not change the indentation style.
  • Follow all guidelines given in class

Archive