CPSC 421-020 Object-Oriented Programming Spring 2025

Archive

• Week 13 Class 24 Thu Apr 17 Posted: Apr 17

  Announcements

  • Project 3 Scores in Brightspace. Total points are 110. Maximum score of 100.
  • Exercises We are all caught up on grading exercises. If you have an issue with any of them, please email me the exercise number, title, and issue.

  • Project 4

    For all projects, you need to follow all the coding and design practices. This means that for added classes, you must have a header comment, include guards, the works.

  • Exercise 79: C++ Inheritance Specifiers Crossword

    This is what I tried to do in class on Tuesday, but the network issues prevented it.

    Do this as extra credit. I will drop another lowest-score exercise.

  Agenda

  • Notes: C++ Constructor Specifiers
  • Exercise 81: C++ Constructor Specifiers Crossword

  • Notes: Design Pattern Composite

    Compose objects into tree structures to represent part-whole hierarchies

    Composite lets clients treat individual objects and compositions of objects uniformly

  • Exercise 82: Design Pattern Composite Crossword

  • Notes: Design Pattern Adapter

    Convert the interface of a class into another interface clients expect

    Adapter lets classes work together with incompatible interfaces

  • Exercise 83: Design Pattern Adapter Crossword
  • Notes: Dependency Injection
  • Exercise 84: Dependency Injection Crossword
  • Notes: PIMPL

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Apr 21

• Week 13 Class 23 Tue Apr 15 Posted: Apr 15

  After Class

  • template pull request

    In your repository.

  Announcements

  • Office Hours Due to in-person College Meeting on Thursday, 10:45 - Noon, office hours this week are:

    • Tuesday, 10:30 - 11:30 am, 3:15 - 4:15 pm
    • Thursday, 3:15 - 4:15 pm

  • Project 3 Sequence Diagram scores and feedback are posted in Brightspace.

    You can leave the issue "Incorrect identity output for XML declarations" open (i.e., you do not have to fix it).

  • Project 4 Due Tuesday, Apr 22

  Agenda

  • Exercise 77: SOLID Crossword

  • Benchmark: reserve() before processing

    • Write without the optimization
    • Verify it works (with an automated testsuite if possible)
    • Perform the optimization
    • Measure and check that the optimization is an improvement
  • Notes: Design Pattern Command
  • Exercise 78: Design Pattern Command Crossword

  • Notes: C++ Inheritance Specifiers

    • C# Contextual Keywords
    • C++ Keywords

  • Exercise 79: C++ Inheritance Specifiers Crossword

    This link is only open during the activity in class.

  • Notes: Design Pattern Strategy

    Define a family of algorithms, encapsulate each one, and make them interchangeable

    Strategy lets the algorithm vary independently from clients that use it

  • Exercise 80 : Design Pattern Strategy Crossword
  • Notes: C++ Constructor Specifiers

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Apr 16

• Week 12 Class 22 Thu Apr 10 Posted: Apr 10

  After Class

  • Project 3: Class Diagram Score and feedback in Brightspace. Not in issues this time.

    Going to work on the Sequence Diagram score and feedback next. Last is the scores for each tag. Note that I am done with the issues.

  Announcements

  • Project 4 Due Tuesday, Apr 22

  • Project 3

    All issues created for tags. Working on feedback on diagrams, and scores on all parts. Reminders:

    • Extension points for XML and the attributes passed as parameters can only be the following:

      XML Extension Point	Attributes
      Start Document
      XML Declaration	version, encoding, standalone
      Element Start Tag	qName, prefix, localName
      Element End Tag	qName, prefix, localName
      Characters	characters
      Attribute	qName, prefix, localName, value
      XML Namespace	prefix, uri
      XML Comment	value
      CDATA	characters
      Processing Instruction	target, data
      End Document

    • It is not a good design to have handlers or callbacks for other parts. Use get accessors if needed.
    • Note that LOC, URL, and other srcfacts concerns are not part of all XML, and the XMLParser should not know about them.

    • Saw lots of public methods, ignoring encapsulation and information hiding. The only methods that should be public are parse(), registering handlers, and perhaps a (very) few get methods. Public methods are for the clients of the class, not for the implementors of the class. There is a cost to every public method. For a real system, all public methods must have:

      • Thorough comments in the include file
      • Thorough external documentation
      • Test cases for each
      • Examples for each
      • Must be maintained throughout the lifetime of the code

      It is easier to just limit the interface (i.e., the public methods) to what is essential to the client code.

  • Exercise 66: Dynamic Dispatch

    Feedback is in the file oracle2.txt in the branch feedback in your repository. The oracle2.txt is the difference between the oracle (with the correct answers) and your Base.cpp. If the oracle2.txt is empty, then that means your answer is correct (reflected in your score). Even if your answer is correct the oracle2.txt may show some differences. The differences were manually examined and I used more direct techniques to determine if there were any static dispatch in your answer.

    There is a strong possibility that this will be in a question on the Final Exam.

  • Exercise 68: FileIO

    Please read over the feedback in Brightspace. Even if you got a 10 points, there may be feedback as to your comments or coding style.

    • All methods should have a comment before the declaration/definition. This includes constructors and destructors. See the notes for a good comment before a destructor.
    • Do not use the term // virtual ... for a comment of a method (or destructor). The keyword virtual tells us that. The following are examples of substandard comments for destructors:

  Agenda

  • Exercise 72: Errors and Exception Handling Crossword

  • Exercise 73: Exceptions

    Take the code for Exceptions.cpp and perform the following changes:

    • Change the maximum length in function g() to 200 in both the code and the output message
    • Change the "not allowed" value from 50 to 75 in function h() in both the code and the output message
    • Change the domain of function f() to allow the negative value -1 (-2 and smaller is still not allowed)

    Run the program once for each exception, and show that the exception is thrown.

    To demonstrate these changes, you will record a terminal session using asciinema. Submit the terminal session using the form You can use GitHub Codespaces for this as it has asciinema installed.

    Use the GitHub Classroom Exceptions invitation link in Brightspace.

  • Notes: Handlers
  • Exercise 74: Handlers Crossword
  • Notes: Design Pattern Factory Method

  • Exercise 75: Design Pattern Factory Method Crossword

    Due by 4:30 pm on Fri Apr 11

  • Exercise 76: Design Pattern Factory Method Quiz

    Complete the quiz. Any incorrect answer is a point off out of 10, so answer very carefully.

    You will see the correct responses after the due date.

  • Notes: SOLID

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Apr 14

• Week 12 Class 21 Tue Apr 08 Posted: Apr 08

  After Class

  • Exercise 70: std::exception Hierarchy Crossword The Brightspace assignment submission is now open.

  Announcements

  • Exercise 63: Names II Feedback in Report2.md in the branch feedback. As with any posted markdown, best to view it on GitHub.
  • Project 3 Rolling out the issues for Project 3. Already posted most of v3a.
  • Project 4

  Agenda

  • Exercise 68: FileIO

    The program ReadFile supports multiple ways to read from standard input. You run the program with the option on the command line. The options include get, read, and fileread:

    

    All is well and good, but the program has memory leaks with some options. Use valgrind to determine what the problem is, fix it, and commit your fix. Do not make any other changes.

    Valgrind performs dynamic analysis, which means it collects data during the execution of a program. For valgrind, running with one option (e.g., using the option get) may find an issue, but running with another option (e.g., using the option read) may not. To be sure, we have to run the program with all options.

    The build command is:

    To run with valgrind for option get:

    This command is a single line displayed using the line continuation character ("\"). You can copy and paste the entire command.

    You must run the command with each option, get, read, and fileread.

    The fix consists of only one change to the code. Your code must pass with a clean valgrind report for all three options.

    The GitHub Classroom link is in Brightspace.

  • Exercise 69: rValue References Crossword

  • Notes: Errors and Exception Handling

    RAIIDataMembers Situation that shows why you should always use RAII types for your data members, and not try to do the memory management outside of that.

  • Exercise 70: std::exception Hierarchy Crossword
  • Notes: API
  • Exercise 71: API Crossword
  • Notes: Handlers

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Apr 09

• Project 4 Posted: Apr 08

  Project 4 continues the work on srcFacts. It is due at 11:59:59 pm Tuesday, Apr 22, and involves the following stages which must be performed in order:

  Tag v4a Correct the issues in XMLParser that affect srcfacts, xmlstats, identity, class diagram, and sequence diagram.

  Tag template Redesign XMLParser to use the Template Design Pattern. In this design pattern, extension points are virtual methods. This means new classes that inherit from XMLParser:

  • srcFactsParser in the new files srcFactsParser.hpp and srcFactsParser.cpp
  • IdentityParser in the new files IdentityParser.hpp and IdentityParser.cpp
  • XMLStatsParser in the new files XMLStatsParser.hpp and XMLStatsParser.cpp

  The pull request template adds these new files to your repository and updates the CMakeLists.txt so that they are part of the build. Update your class and sequence diagrams to show this new design.

  As before, our XML parser needs to provide access to all parts of XMLvia the following extension points from [XML notes slide 33]

  XML Extension Point	Attributes
  Start Document
  XML Declaration	version, encoding, standalone
  Element Start Tag	qName, prefix, localName
  Element End Tag	qName, prefix, localName
  Characters	characters
  Attribute	qName, prefix, localName, value
  XML Namespace	prefix, uri
  XML Comment	value
  CDATA	characters
  Processing Instruction	target, data
  End Document

  Tag handler Extract a handler from XMLParser called XMLParserHandler, a new class that only handles the user-defined processing (what we previously had as callbacks). Put the entire XMLParserHandler class in the file XMLParserHandler.hpp.

  Then change srcFactsParser, IdentityParser, and XMLStatsParser to inherit from XMLParserHandler instead of XMLParser, and rename them by replacing "Parser" in the name with "Handler". You can rename the srcFacts files using git:

  Note you will have to commit and push these changes.

  You will also have to rename these files in your CMakeLists.txt. Update your class and sequence diagrams to show this new design.

  Also make sure to update the class names and header comments.

  Warning Once you tag template and move on to handler, you will not be able to change anything for template. So carefully check that you are done with the template part before you tag it and move on to handler

  One prevalent issue in these conversions is that changing XMLParser and srcfacts will cause identity and xmlstats to break until they are converted. To avoid this, understand that make uses the default target all and means make all. So instead of building all executable targets, build them separately as needed, e.g., make srcfacts, make xmlstats, or make identity.

  Keep in mind:

  • You are required to implement these steps in the order given, i.e., tag v4a, tag template, and then tag handler
  • At every commit, ensure the project compiles, builds, and produces the correct answer. Note that it may be only one of the executable targets that builds during conversion.
  • The Template Design Pattern has absolutely nothing to do with the C++ language feature templates. Any use of C++ templates will result in a 0.

• Week 11 Class 20 Thu Apr 03 Posted: Apr 03

  Announcements

  • Square Brackets

    Some of you are having issues with showing multiplicity in your yuml class diagrams. I showed multiple examples of this in class, but forgot how I got it originally working. First take a look at this diagram and the corresponding yuml input and note the square brackets for multiplicity:

    

    The square brackets around the entire class are not the same as the multiplicity brackets, as the multiplicity brackets:

    • Are shifted up as compared to the outer brackets
    • Have whitespace to the left of the '［' bracket and to the right of the '］' bracket. That is not a space next to them. It is part of the character.

    These are called fullwidth square brackets. That is where I originally got them from.

    So how do you use them? You can copy them from the examples above and paste them in. The hex unicode for regular brackets are U+005B and U+005D, and for the fullwidth brackets U+FF3B and U+FF3D.

  • Exercise 55: Names

    Score in Brightspace. Feedback in Report.md in the repo.

    There is a strong possibility that this will be in a question on the Final Exam.

  • Exercise 62: Static Dispatch

    Feedback is in the file oracle.txt in the branch feedback in your repository. The oracle.txt is the difference between the oracle (with the correct answers) and your Base.cpp. If the oracle.txt is empty, then that means your answer is correct (reflected in your score). Even if your answer is correct the oracle.txt may show some differences. The differences were manually examined and I used more direct techniques to determine if there were any dynamic dispatch in your answer.

    There is a strong possibility that this will be in a question on the Final Exam.

  Agenda

  • Exercise 63: Names II

    Using the feedback in the Report.md, fix your Names code.

    If you have no changes to make (based on the feedback), leave the code alone.

  • Notes: Design Patterns
  • Exercise 64: Design Patterns Crossword
  • Notes: Design Pattern Template Method
  • Exercise 65: Design Pattern Template Method Crossword

  • Exercise 66: Dynamic Dispatch

    The repository Base has a set of various method call situations, and a way at run time (using assert()) to verify which method is actually called.

    • If the call is performed using dynamic dispatch then complete the assert() in the code that indicates (via a string) which method is called, e.g., for m2() is it "Base::m2()", "Derived::m2()", or "DerivedDerived::m2()"?
    • If the call is performed using static dispatch then comment out the assert(), e.g.,

    Handle each assertion one at a time in order, compiling and running the program (i.e., make run) after each assertion is completed. The assertion you edited should pass, and you should be onto the next assertion.

    You are required to commit for each block of statements in the main program.

  • Exercise 67: VTable Diagram

    There is no standard diagram to show a vtable. These are my own created using dot notation with GraphViz. GraphViz is for general graph visualization. You can create UML diagrams in GraphViz, but you have to much more work yourself, unlike yuml. Many of the more complex UML Class Diagrams in the notes, especially for design patterns, use GraphViz as it provides more control over the arrangements of the nodes (classes). The vtable diagrams in the notes were originally done as modified UML Class Diagrams in yuml, e.g., VTable Base Pointer but I converted them to GraphViz.

    In this exercise, you will complete a VTable diagram with a new class, Rectangle, which inherits from the class Shape.

    The diagram already has all classes and all method definitions. You just have to complete the vtable so that the method pointers in the vtable point to the correct function.

    The easiest way to work with the diagram is with GraphVizOnline. Start with the base diagram, and add the dot notation for the vtable method pointers to the correct methods. You can use the Shape and Circle VTable Diagram for an idea of how to get the edges from the Rectangle vtable to the functions.

    To get credit, all edges must be correct.

    You can also convert the VTableRectangle.dot file using the command-line tool, dot

    The dot program is available on macOS and WSL/Linux with the package graphviz. I also added it to the GitHub Codespaces image.

    Note that dot is part of a number of graph-drawing algorithms (see man dot). This one uses fdp to control the placement of the nodes.

  • Notes: Virtual Destructors
  • Notes: rValue References

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Apr 7.

• Week 11 Class 19 Tue Apr 01 Posted: Apr 01

  After Class

  • Square Brackets

    Some of you are having issues with showing multiplicity in your yuml class diagrams. I showed multiple examples of this in class, but forgot how I got it originally working. First take a look at this diagram and the corresponding yuml input and note the square brackets for multiplicity:

    

    The square brackets around the entire class are not the same as the multiplicity brackets, as the multiplicity brackets:

    • Are shifted up as compared to the outer brackets
    • Have whitespace to the left of the '［' bracket and to the right of the '］' bracket. That is not a space next to them. It is part of the character.

    These are called fullwidth square brackets. That is where I originally got them from.

    So how do you use them? You can copy them from the examples above and paste them in. The hex unicode for regular brackets are U+005B and U+005D, and for the fullwidth brackets U+FF3B and U+FF3D.

  Announcements

  • Midterm Exam The Midterm Exam scores and feedback are in Brightspace.

    Midterm Exam

  • Project 3 Due date extended to Thursday, Apr 3.

  • Project 2

    I found two issues that I created were incorrect. They both involved a blank line after the filename in a header comment.

    I added the label false positive to the issue in GitHub. I considered deleting the issue, but that would lose the history, including your comments.

    For the score, if you did v2c, I added a point to your v2c score and your overall score. Each issue was worth 0.5 points.

  • CPSC 480 Software Engineering (SE)

    I also cover the SE course, which is offered in Fall, 2025. It will not be offered in Spring, 2026.

  • std::string_view IN Parameters Pass std::string_view by value instead of const reference

    Coding Standard - std::string_view

    Make sure to fix this in Project 3.

  • Guide: Inline Lambdas

    I expect you to follow this guideline for Project 3.

    If you really don't like passing a long list of inline lambdas, the problem is not the lambda's but the long list. Consider using register methods

    BTW, whenever you do use a named lambda, use auto for the type. Declaring a type for a named lambda is quite tricky to figure out. Using a std::function for the local variable is not necessary.

  Agenda

  • Notes: UML Association
  • Exercise 59: UML Association Crossword
  • Notes: UML Generalization
  • Exercise 60: UML Generalization Crossword
  • Notes: Dispatch
  • Exercise 61: UML Dispatch Crossword

  • Exercise 62: Static Dispatch

    The repository Base has a set of various method call situations, and a way at run time (using assert()) to verify which method is actually called. Each assertion needs to have one of the following done:

    • If the call is performed using static dispatch then complete the assert() in the code that indicates (via a string) which method is called, e.g., for m1() is it "Base::m1()", "Derived::m1()", or "DerivedDerived::m1()"?

    • If the call is performed using dynamic dispatch then do not fill in the answer for the call, but instead comment out the assert(), e.g.,

    Handle each assertion one at a time in order, compiling and running the program (i.e., make run) after each assertion is completed. The assertion you edited should pass, and you should be onto the next assertion.

    You are required to separately commit for each block of statements in the main program.

    The GitHub Classroom Invitation Link for Base is in Brightspace.

  • Notes: VTables

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Apr 02

• Week 10 Class 18 Thu Mar 20 Posted: Mar 20

  After Class

  • Midterm Exam The Midterm Exam scores and feedback are in Brightspace
  • Availability During Spring Break I am only available over Spring Break for questions on Project 3. Feel free to send questions about Project 3.

  • Project 2

    I found two issues that I created were incorrect. They both involved a blank line after the filename in a header comment.

    I added the label false positive to the issue in GitHub. I considered deleting the issue, but that would lose the history, including your comments.

    For the score, if you did v2c, I added a point to your v2c score and your overall score. Each issue was worth 0.5 points.

  Announcements

  • Exercise 49: Convert II This exercise is extra credit. I will drop another lowest-exercise score.

  • Exercise 54: Memory Due Date extended.

    I gave a score and any feedback to those who successfully completed the exercise so they can then work on Memory II.

    If you did not get a score, then one of the following applies:

    • No repository created
    • No commits
    • No proper tag exists in your repository at GitHub
    • Warnings from the compiler still exist
    • valgrind does not show a clean run with no memory leaks
    • Added calls to consumer()

    Whatever the reason above, I will allow you to fix it.

  • Producer/Consumer

    Some of you treated the function consumer() as a function for deleting memory. That is not the entire purpose of consumer(). This is indicated by the:

    which is the universal (code example) symbol for "Other processing will occur, but we are ignoring for now to make a point". Some example of what could occur in producer/consumer, in addition to memory allocation/deallocation:

    Scenario	Producer Action	Consumer Action
    Image Processing	Load an image from disk	Process the image (apply filters, resize, save output)
    Logging	Create a log entry with explanation, severity, and timestamp	Write the log entry to a file
    Database Connection	Initialize a database connection	Use the connection to execute a query or transaction
    Asynchronous Task Processing	Produce work items (e.g., tasks)	Retrieve a task from a shared queue and process

  Agenda

  • Guide: Default lambda Capture
  • Notes: Coupling
  • Exercise 57: Coupling Crossword

  • Exercise 49: Convert II

    Following my example in class as we rearrange the concerns and apply changes to the file to separate the concerns.

    std::for_each

    Convert020

  • Exercise 58: Memory II

    Note that Exercise 54: Memory is a prerequisite.

    Replace the raw pointers (e.g., int* p) with std::unique_ptr<int>. Ensure it runs successfully and you have a clean Valgrind run. The include file for std::unique_ptr is <memory>. Once done, tag this in Git as smartpointer

  • Notes: UML Association
  • Exercise 59: UML Association Crossword Due after next class meeting

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

• Week 10 Class 17 Tue Mar 18 Posted: Mar 18

  After Class * Exercise 49: Convert II This exercise is extra credit. I will drop another lowest-exercise score.

  Announcements

  • Catching Up Behind on responses to Project 2 issues
  • Office Hours Additional Office Hours today, Tue Mar 18 from 10:30 - 11:30 am.
  • Project 3

  Agenda

  • Exercise 52: Lambda

    Follow along in your commits as we explore what we can get from the context of the lambda definition.

    Lambda-020

  • Notes: UML Class Relationships
  • Exercise 53: UML Class Relationships Crossword
  • Guide: Valgrind

  • Exercise 54: Memory

    The file Memory.cpp in the repository Memory contains many memory resource problems described in the notes.

    Compile and run the program on your platform (i.e., your compiler and operating system). You may or may not see a memory-related issue during the build and run.

    Go to a system where you can run valgrind. Following the instructions in the Guide: Valgrind, compile and run valgrind on the program.

    Fix the memory resource problems in Memory.cpp without using std::unique_ptr. Do this for each section one by one committing each section separately. Get the code to the point where it compiles and runs successfully, and you have a clean Valgrind run.

    Once done, tag this in Git as memoryfixed.

  • Exercise 55: Names

    The UML Class Diagram shows Name with attributes that are single-value optionals.

    Convert the source code class to use std::optional<std:string> instead of the pair of std::string and a boolean flag.

    The link for GitHub Classroom is in Brightspace.

    Due 4:30 pm on Friday, Mar 21

    Reminder The type String in a UML Class Diagram does not necesarily map to a std::string in a C++ program. It could map to a std::string_view, or even a c-string. Which source-code type a UML type maps to is part of the code implementation, and not part of the model*.

    

  • Exercise 49: Convert II

    Following my example in class as we rearrange the concerns and apply changes to the file to separate the concerns.

    std::for_each

    Convert020

  • Notes: Dependencies
  • Exercise 56: Dependencies Crossword Due 4:30 pm on Friday, Mar 21
  • Notes: Coupling

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

• Project 3 Posted: Mar 13

  The main problem with the design for the srcFacts project is the complicated section of code (the large while loop with the main nested-if) surrounding the srcFacts concerns. We have moved much of the low-level parsing details out of srcfacts.cpp (and into XMLParser), but that overall code structure remains.

  Change the design of XMLParser to use full IoC (Inversion of Control). IoC lets you move the large while loop with nested-if entirely into an XMLParser method parse(). The only things that srcFacts will have to do (and the only public methods of the new XMLParser) are the parse() method and (depending on your implementation) methods to register handlers.

  Your XML parser needs to provide access to all parts of XML, even if srcFacts does not use it, via the following extension points from XML notes slide 34

  XML Extension Point	Attributes
  Start Document
  XML Declaration	version, encoding, standalone
  Element Start Tag	qName, prefix, localName
  Element End Tag	qName, prefix, localName
  Characters	characters
  Attribute	qName, prefix, localName, value
  XML Namespace	prefix, uri
  XML Comment	value
  CDATA	characters
  Processing Instruction	target, data
  End Document

  There is no explicit part or tag to fix the code from the Project 2 feedback. Fix any style issues in XMLParser or any issues that will cause a problem with Project 3.

  Tag v3a: Redesign XMLParser to use IoC with lambda handlers for the extension points. For srcFacts, this means that the lambda functions in srcFacts.cpp contains all the processing of the XML data results, e.g., tag names with none of the XML parsing. Update your Class Diagram and Sequence Diagram to reflect this new design. Rules apply:

  • Each extension point has a single handler
  • All data passed to the handlers must be via parameters
  • Handlers cannot call XMLParser methods

  Tag v3xmlstats: Create the application xmlstats that produces a markdown report (similar to what srcFacts does) that indicates the number of each part of XML. E.g., the number of start tags, end tags, attributes, character sections, etc.

  Tag v3identity: Create the application identity which is an identity transformation. A transformation is a program that converts data in one format to data in a related format, typically the same format. In this case, it converts from XML to XML. It is an identity transformation because the output XML should be the same (as much as possible) as the input XML. The XMLParser will parse the input, and your callbacks will output the XML format. You can assume that there are no CDATA parts, but you must escape all >, <, and & in Character and CDATA content.

  Note: Any changes to XMLParser must work with srcfacts, xmlstats, and identity:

  • You cannot have a special XMLParser for each application. Only one XMLParser is allowed.
  • Any srcfacts, xmlstats, or identity-specific concerns cannot remain in XMLParser
  • All three applications, srcfacts, xmlstats, and identity cannot contain any other application concerns. For example, no LOC (Lines Of Code) is collected in xmlstats.

  All tags for Project 3 are due Tuesday, Apr 2 Thursday, Apr 3.

  Keep in mind:

  • Complete tag v3a first. After that, you can complete tags v3xmlstats and v3identity in any order.
  • I will provide pull requests for the programs xmlstats and identity that add the needed files to the build.
  • At every commit, ensure the project compiles, builds, and produces the correct answer.

• Week 9 Class 16 Thu Mar 13 Posted: Mar 13

  After Class

  • UML Class Relationships Crossword Fixed the link.
  • Due Dates Due to not completing much of the material in section 020, the due dates for both sections are moved to Wednesday, Mar 19.
  • Section 020 2-3:15 pm We will finish what we did not cover on Thursday on Tuesday.

  Announcements

  • Office Hours A late-added Department Meeting from 10:45 am - Noon will conflict with my Office Hours. I will be available from 10:30 - 10:45 am. I am very certain that this will be a short meeting (there is one topic), so email me and I can email you back when I am done.

  • Project 2 Scores

    • Scores in Brightspace
    • v2a, v2b, v2c, v2d, v2e - Each worth 16%
    • Class Diagram, Sequence Diagram - Each worth 10%
    • Most feedback in GitHub issues
  • Project 3

  Agenda

  • Notes: Lambda Functions For reference

  • Exercise 52: Lambda

    Follow along in your commits as we explore what we can get from the context of the lambda definition.

    Lambda-020

  • Notes: UML Class Relationships
  • Exercise 53: UML Class Relationships Crossword

  • Exercise 49: Convert II

    We did not get to this, so it is delayed again.

    Following my example in class as we rearrange the concerns in the file to separate them.

    Convert020

  • Guide: Valgrind

  • Exercise 54: Memory

    The file Memory.cpp in the repository Memory contains many memory resource problems described in the notes.

    Compile and run the program on your platform (i.e., your compiler and operating system). You may or may not see a memory-related issue during the build and run.

    Go to a system where you can run valgrind. Following the instructions in the Guide: Valgrind, compile and run valgrind on the program.

    Fix the memory resource problems in Memory.cpp without using std::unique_ptr. Do this for each section one by one committing each section separately. Get the code to the point where it compiles and runs successfully, and you have a clean Valgrind run.

    Once done, tag this in Git as memoryfixed.

  • Demo: Too many open files
  • Notes: Dependencies

  Unless otherwise noted, exercises are due by 4:30 pm on Mon, Mar 17 Wed, Mar 19.

• 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.

    Convert020

  • 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.

    Convert020

    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-020.

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

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

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

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

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

    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  2:00 - 3:15 pm in (CAS) room 144