EECE 2140 · Week 8 · Class Project · Complete worked solution

Dynamic Sensor Recorder

Week #08 Mini Project: Expandable Measurement Collection

Plan, implement, test, document, and release a complete console application. Allow 1–2 hours; the reference capstone can take longer.

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. Understand the acceptance criteria

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

InputExpected output
3 2 4 6
Mean: 4
0
Invalid count
2 1 x
Invalid reading

Each row is an executable acceptance test. Input is read from standard input; output is printed to the terminal.

2. Create the repository and project folders

Create an empty GitHub repository named week08-class-project with a README, then substitute your username:

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

3. Implement the complete solution

The following source is the worked solution. Read it first, predict the test results, then create the file from your terminal:

cat > src/main.cpp <<'EOF'
#include <iostream>
int main(){int n;if(!(std::cin>>n)||n<1||n>1000){std::cout<<"Invalid count\n";return 0;}double* readings=new double[n];double total=0;for(int i=0;i<n;++i){if(!(std::cin>>readings[i])){delete[] readings;std::cout<<"Invalid reading\n";return 0;}total+=readings[i];}std::cout<<"Mean: "<<total/n<<"\n";delete[] readings;}
EOF

4. Create test fixtures

cat > tests/input1.txt <<'EOF'
3 2 4 6
EOF
cat > tests/expected1.txt <<'EOF'
Mean: 4
EOF
cat > tests/input2.txt <<'EOF'
0
EOF
cat > tests/expected2.txt <<'EOF'
Invalid count
EOF
cat > tests/input3.txt <<'EOF'
2 1 x
EOF
cat > tests/expected3.txt <<'EOF'
Invalid reading
EOF

5. Build and test from the terminal

cat > test.sh <<'EOF'
#!/usr/bin/env bash
set -eu
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
./build/app < tests/input2.txt > build/actual2.txt
diff -u tests/expected2.txt build/actual2.txt
./build/app < tests/input3.txt > build/actual3.txt
diff -u tests/expected3.txt build/actual3.txt
echo "All acceptance tests passed"
EOF
bash test.sh

The script stops on a compilation error or mismatched output. Successful completion prints “All acceptance tests passed”.

Memory check

g++ -std=c++17 -g -fsanitize=address,undefined src/main.cpp -o build/memory-check
./build/memory-check < tests/input1.txt

Run under Ubuntu/WSL. Investigate sanitizer diagnostics and explain why delete[] is required on both success and invalid-reading paths. Later, compare this manual ownership example with Week 14’s vector-based design.

6. Automate with GitHub Actions

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
git add src tests test.sh .github .gitignore
git commit -m "Implement application with acceptance tests and CI"
git push -u origin feature/implementation

Open a pull request in GitHub, inspect its Actions logs, and merge only after checks pass. Intentionally alter one expected-output line on a temporary branch, observe the failure, then restore it. Do not change expectations to hide a defect.

7. Document and verify a release

Write README.md with purpose, input format, build/run/test commands, example output, limitations, and AI assistance. Include a short debugging reflection.

git switch main
git pull --ff-only
# Edit and commit README.md, then push.
cd ..
git clone https://github.com/YOUR-USERNAME/week08-class-project.git week08-verify
cd week08-verify
bash test.sh
git tag -a v1.0 -m "Verified class project"
git push origin v1.0

Completion: a fresh clone passes, the latest CI run is green, and the instructions reproduce your output.

Download and engineering review

Download the complete solution, tests, README, and workflow

Explain the data flow, validation choices, and how each test detects a failure. The downloadable solution is a learning reference, not a substitute for understanding the code.