Expandable Measurement Collection

Tools, prerequisites, and learning objectives

Tools: Ubuntu terminal (Linux or Windows with WSL), g++ supporting C++17, Git, Bash, a GitHub account, and an optional editor. File projects use supplied text fixtures. Week 3 also uses GDB; Week 8 uses compiler sanitizers.

Prerequisites: Dynamic allocation, pointers, ownership, and deletion.

Objectives: Bound allocations; release owned memory on all paths; check memory errors.

Provisional course alignment: C++ implementation, problem solving, development tools, testing, and technical communication; team projects additionally assess collaboration. Exact official syllabus objective numbers have not been supplied.

g++ --version
git --version
# Install missing tools in Ubuntu:
sudo apt update
sudo apt install build-essential git gdb

1. Agree on requirements and tests

• Implement a dynamically allocated collection with a documented capacity limit.
• Support appending readings and removing the last reading.
• Release owned storage correctly; prevent overflow and empty removal.

Required test scenarios

• Append two values then remove one preserves the first
• Removing from empty is handled
• Capacity boundary is enforced

Before coding, agree on exact input/output formats and expected results for these scenarios. Add one extra edge case of your own. This assignment deliberately does not supply the application solution.

2. Assign responsibilities

Assign implementation, testing, automation, and documentation/release roles; combine the last two for a three-person team. Rotate roles from last week. Every member must commit meaningful work, run the tests, and review a teammate’s pull request.

3. Set up GitHub collaboration

One member creates week08-mini-project with a README and invites collaborators. Create issues for requirements, implementation, tests, CI, and documentation. Each member runs:

git clone https://github.com/TEAM-OWNER/week08-mini-project.git
cd week08-mini-project
git switch -c feature/YOUR-TASK
mkdir -p src tests .github/workflows
printf "build/\n" > .gitignore

4. Implement and test in the terminal

Create src/main.cpp and test fixtures from your agreed specification. Adapt the class project’s test.sh to your application, including every required scenario. Do not retain its expected results unchanged.

mkdir -p build
g++ -std=c++17 -Wall -Wextra -pedantic src/main.cpp -o build/app
./build/app < tests/input1.txt > build/actual1.txt
diff -u tests/expected1.txt build/actual1.txt
bash test.sh

For a different command-line interface, update both README and test.sh consistently. Tests must return a nonzero exit status on failure.

5. Add automated checks

Use this workflow to run your team’s own test script:

cat > .github/workflows/cpp.yml <<'EOF'
name: Build and test
on: [push, pull_request]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Compile and run acceptance tests
        run: bash test.sh
EOF

Prove it detects a failure: push an intentional mismatch on a branch, inspect the failed run, then correct it before merging. Keep evidence of both runs.

6. Review, merge, and synchronize

git status
git add YOUR-CHANGED-FILES
git commit -m "Describe your completed feature and tests"
git push -u origin feature/YOUR-TASK

Replace placeholders with actual file and branch names. Open a pull request linked to its issue. A teammate reviews correctness, tests, naming, and generated files. Resolve feedback and merge after CI passes.

git switch main
git pull --ff-only
git switch -c feature/NEXT-TASK

7. Reproduce and release

cd ..
git clone https://github.com/TEAM-OWNER/week08-mini-project.git week08-team-verify
cd week08-team-verify
bash test.sh
git tag -a v1.0 -m "Verified Week 8 mini project"
git push origin v1.0

Have someone other than the implementation lead perform this check. Record each member’s contributions and review links in CONTRIBUTIONS.md.

Deliverables and assessment

• Repository and tagged-release links; complete source, tests, and Actions workflow.
• README: setup, input/output contract, terminal commands, limitations, and AI-use disclosure.
• Passing CI plus a demonstrated failure/correction.
• Reviewed pull requests, contribution record, and each member’s terminal evidence.
• Short demo explaining the week-specific concepts and design tradeoffs.