CPSC 421 Object-Oriented Programming (OOP) Spring 2023

News

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

  After Class

  • Crosswords

    Crossword Labs had an update in the past couple of days. Printing is much more standard. So now you can

    1. Print using the Print feature in your browser
    2. Use the print button

  • Project 1 v1d General principles that I carefully went over and emphasized, but are being overlooked.

    • A design change must not break the build. If you extract a function and the program does not build, you must fix it before going on. E.g., make
    • A design change must not change the output of the program. If you extract a function and the output of the program is not the same, you must fix it before going on. E.g., make run, and verify the result.
    • Proper Direction of parameters
    • XML Interface Concepts are the only things that our XML functions can pass OUT.
    • Accessor::Predicate Stereotype
    • When to Use an Accessor::Predicate Stereotype

  Announcements

  • A question was raised that either Aggregate.hpp or Aggregate.cpp did not have a newline at the EOF for one of the commits. For a demonstration that they did, Rainfall-010
  • Spring 2023 Career Fair Class attendance is still expected. If you want to attend the other section of OOP, email me for class to check
  • Project 1 Do not wait until the last minute. This part is much more involved and have you extracting multiple functions.

  • Project 1 Pull Request

    I created a pull request for Project 1 to create the (empty) files, xml_parser.hpp and xml_parser.cpp for part v1d. The easiest way to merge this into your code is the Merge pull request at GitHub. Once you merge, then remember to do a git pull in all of your cloned repositories.

    Note that xml_parser.{hpp,cpp} expands to xml_parser.hpp and xml_parser.cpp in a shell.

  • Guide: srcML

  Class

  • Notes: Concerns

  • Exercise 16: srcFacts Concerns- Handout in class, due by the end of the class meeting

    • srcFacts.cpp#L433-L473
    • srcFacts.cpp#L283-L292
    • srcFacts.cpp#L548-L556
    • srcFacts.cpp#L317-L324
  • Exercise 17: Concerns Crossword
  • Notes: Vertical Development
  • Interlude: Guide: Benchmarks
  • Notes: Function Generalization
  • Notes: Naming

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

• Project 1: srcFacts Posted: Jan 18

  One approach to understanding the source code of a system is to count things, e.g., the number of statements, functions, classes, expressions, LOC (Lines Of Code), etc. The program srcFacts produces a report of these counts.

  It is very difficult for a program to directly parse C++ source code, i.e., identify the syntactic parts of the code. 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 collecting counts, and produces the report.

  The srcFacts program is one large, main() function using almost no design features. It does have high scalability and performance as it is extremely fast and, for example, can produce a report on the entire Linux kernel in under 6 seconds. However, it is not easy in its current form 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. It has no modularity, extensibility, reusability, and specifically no maintainability.

  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. The heading in the table must be "Returns". Due Jan 24

  Tag v1b Move the refillContent() function into the separate refillContent.hpp and refillContent.cpp files. Due Jan 26 27

  Tag v1c Apply the specific design changes from the Coding Practices Task List (to appear). As you verify that the code follows the practices given, check them off. Once you have completed all of them, close the issue. Due Jan 29 31 Feb 1

  Tag v1d Extract a set of (free) functions to handle the low-level details of the XML parsing. Extract one function at a time, i.e., each commit can only include a single extracted function. These function declarations and definitions belong in the files xml_parser.hpp and xml_parser.cpp, as described above. Due Feb 2 6 9

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

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

  • 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 absolutely 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 are free to 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.