WikiLabs - Contribuții utilizator [ro]

SDPT Lab 9

2026-05-18T15:38:13Z

Rhobincu: /* Tasks */

= Week 9 Lab Activity: Dynamic Analysis with Sanitizers and Valgrind =

== Objective ==

Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</code> stage that builds the project under AddressSanitizer and UndefinedBehaviorSanitizer and runs your full test suite against the instrumented binary. By the end of this lab, your pipeline catches a fourth class of bug - runtime memory errors and undefined behavior - automatically on every push.

== Background ==

You will add a new CMake build type called <code>Sanitize</code> that compiles with <code>-fsanitize=address,undefined</code> alongside <code>-O1 -g -fno-omit-frame-pointer</code>. The <code>-O1</code> keeps the optimizer light enough that sanitizer reports stay readable; <code>-g</code> embeds debug information so backtraces have line numbers; <code>-fno-omit-frame-pointer</code> ensures those backtraces are actually complete on x86_64.

The sanitizers report errors by printing to stderr and exiting with a nonzero status. This means your existing GoogleTest tests do not need any modification: if a test triggers a sanitizer error, the test binary aborts, ctest reports failure, the CI job fails, and the MR is blocked. The pipeline plumbing from Week 6 carries this work for you for free.

In addition to the sanitizer build, you will run Valgrind manually once against the same codebase. The two tools are complementary: ASan is fast and runs in CI; Valgrind is slow but sometimes catches things ASan misses (notably uninitialized reads, which require MemorySanitizer to catch with sanitizers - and you saw in the lecture why MSan is impractical).

You will also reuse <code>gcovr</code> from Week 4. Dynamic analysis can only find bugs on code paths your tests actually execute, so coverage is part of the deliverable.

The point of this lab is not to introduce new tools you have never seen - you have met all four (ASan/UBSan/Valgrind/gcovr) in lectures. The point is to wire them together into your existing pipeline and prove the wiring works by deliberately breaking things.

Documentation pointers: <code>man valgrind</code>, the AddressSanitizer wiki at https://github.com/google/sanitizers/wiki/AddressSanitizer, the UBSan documentation at https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html, and your existing gcovr docs.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Extend the Docker build environment.''' Update your <code>Dockerfile</code> to install <code>valgrind</code> alongside the tools already present. Rebuild and verify with <code>valgrind --version</code>. The sanitizers themselves ship with the compiler, so no separate package is needed - but confirm by running <code>echo "int main(){}" | g++ -fsanitize=address -x c++ - -o /dev/null</code> inside the container; if that succeeds, ASan is available.
# '''Add the Sanitize build type to CMake.''' In your <code>CMakeLists.txt</code>, add logic that, when <code>CMAKE_BUILD_TYPE</code> equals <code>Sanitize</code>, sets compile and link options for <code>-fsanitize=address,undefined</code> plus <code>-O1 -g -fno-omit-frame-pointer</code>. Make sure both compile ''and'' link options include the sanitizer flag - if you forget the link side, you will get cryptic linker errors about missing <code>__asan_*</code> symbols. Test locally: <code>cmake -B build-san -DCMAKE_BUILD_TYPE=Sanitize</code>, then build, then run a test binary directly to confirm it produces output that mentions ASan.
# '''Run your existing tests under the sanitizers and clean up.''' Run <code>ctest --test-dir build-san --output-on-failure</code>. If any tests fail due to sanitizer reports, fix the underlying bugs in the Oven Controller code (do '''not''' suppress them). Typical findings in EE-trained codebases: forgotten <code>delete[]</code>, signed overflow in temperature math, reading from a member variable that was never initialized in a constructor. Each fix should be its own small commit with a message describing what the sanitizer reported.
# '''Add a sanitize stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>sanitize</code> stage after <code>test</code>. The job should: configure a <code>Sanitize</code> build, compile it, and run <code>ctest</code> against it. Use your existing Docker image. The job must fail the pipeline on any sanitizer error.
# '''Trigger ASan on purpose.''' On your feature branch, introduce a deliberate '''heap-buffer-overflow''' bug somewhere in the production code. Push, watch the <code>sanitize</code> stage fail, capture the ASan report (the job-log permalink in the MR description is sufficient), then revert. Your goal is to see the full ASan diagnostic - the line with the offending access, the line of the allocation, and the "stack-buffer-overflow" or "heap-buffer-overflow" classification.
# '''Trigger UBSan on purpose.''' Repeat with a deliberate '''signed integer overflow''' or '''null pointer dereference'''. The UBSan report looks different from ASan's - a one-line "runtime error" message at the trigger point. Capture, revert.
# '''Trigger LeakSanitizer on purpose.''' Repeat with a deliberate memory leak (allocate something on the heap, do not free it). LeakSan reports at program exit, not at the leak site. Capture, revert.
# '''Run Valgrind once, manually.''' Build your project in a normal Debug configuration (no sanitizers - they conflict with Valgrind's instrumentation). From inside your Docker container, run <code>valgrind --leak-check=full --show-leakkinds=all --track-origins=yes ./your_test_binary</code>. Save the full output. If Valgrind reports any errors that ASan did not, fix them. Add a paragraph to your MR description noting which tool caught what, or that the two agreed completely.
# '''Re-check coverage.''' Recall from Week 4: <code>gcovr -r .. --html-details</code> against a coverage-instrumented build. Generate a current coverage report. Compare against your Week 4 baseline. If coverage dropped, write enough additional tests to bring it back. Coverage gaps are places where sanitizer findings are silently impossible, so this is part of the dynamic-analysis story even if the tool is the same one you used in Week 4.
# '''Document the cost.''' Compare the wall-clock time of your full pipeline before and after this lab. The <code>sanitize</code> stage adds work; document by how much in your MR description. As in Week 7, "the sanitize stage adds 6 minutes and we caught two real bugs" is a more honest finding than rounding to "negligible".
# '''Review and merge.''' Open the MR. The reviewer should check: the Sanitize build type works locally and in CI, that the three deliberate-bug pipeline runs are visible, that the Valgrind output is referenced in the MR, that coverage has not regressed.

== Stretch tasks (optional, if you finish early) ==

Pick at most one. None earn extra points; all teach you something useful.

* '''Add a second sanitizer build.''' Some teams maintain two CI jobs: one with ASan+UBSan, one with ThreadSanitizer. Add a TSan job that builds with <code>-fsanitize=thread</code> and runs the tests. Even on single-threaded code this is harmless, and it sets you up for the day you add concurrency.

* '''Valgrind in CI.''' Add a manual-trigger CI job (using GitLab's <code>when: manual</code>) that runs Valgrind on your test binary. It is too slow to run on every push, but a one-click button for the weekly deep audit is valuable.

* '''Coverage threshold gate.''' Use <code>gcovr --fail-under-line N</code> to fail the pipeline if line coverage drops below a threshold you choose (e.g. 80%). Now coverage is also an automatic quality gate, not just a number.

* '''Sanitizer-specific environment variables.''' Read the docs for <code>ASAN_OPTIONS</code> and <code>UBSAN_OPTIONS</code>. Add <code>halt_on_error=1</code> and <code>abort_on_error=1</code> to your CI environment, which makes the first error a hard stop instead of letting the program limp on. Useful for getting clearer reports.

== Deliverables ==

For this lab to be considered complete, your <code>main</code> branch must contain:

# A <code>Dockerfile</code> that installs <code>valgrind</code> in addition to the previous week's tooling.
# A <code>CMakeLists.txt</code> with a working <code>Sanitize</code> build type.
# A <code>.gitlab-ci.yml</code> with a <code>sanitize</code> stage running after the <code>test</code> stage.
# A merged Merge Request whose linked Issue (or MR description) contains:
## References to '''three''' failed pipeline runs from Tasks 5, 6, and 7 (one each for ASan, UBSan, and LeakSan), with the relevant snippet of each sanitizer's report quoted briefly.
## The Valgrind output from Task 8, or a permalink to it (a job artifact or a gist).
## A note comparing Valgrind's findings with the sanitizers' findings (Task 8).
## The coverage comparison from Task 9 (before/after, plus what you did about it).
## The pipeline cost comparison from Task 10.

The VPL deliverables include the first three files which will be the only ones graded.

== Common pitfalls ==

* '''Linker errors mentioning <code>__asan_*</code> or <code>__ubsan_*</code> symbols.''' You set the sanitizer flag for compilation but forgot to also pass it at the link step. In CMake, both <code>add_compile_options</code> and <code>add_link_options</code> need <code>-fsanitize=...</code>.

* '''Sanitizers and Valgrind conflict.''' You cannot run a sanitizer-built binary under Valgrind. They both rely on intercepting memory accesses and the interception clashes. Build a separate Debug binary (no sanitizers) when you want to run Valgrind.

* '''ASan reports look truncated or have <code>??</code> in the backtrace.''' Almost always means missing <code>-g</code> or missing <code>-fno-omit-frame-pointer</code>. Without frame pointers, the unwinder on x86_64 falls back to imperfect heuristics.

* '''The pipeline passes locally but ASan errors only appear in CI.''' Check that your container image is using a recent enough compiler. GCC's ASan got significantly better between 8.x and 11.x; UBSan added several checks in the same span. The Debian Bookworm <code>g++</code> (12.x) is fine.

* '''Tests pass under the sanitizers locally, but a teammate's machine shows different errors.''' ASan and UBSan are deterministic for a given binary, but slight platform differences (libc version, glibc malloc settings) can occasionally surface bugs that are real but only fire on one machine. The CI container is the source of truth.

* '''Valgrind reports complaints in the standard library.''' Usually you can ignore these unless they reference your own code. Use <code>--suppressions=/usr/share/valgrind/default.supp</code> (most distributions ship a default suppression file) to filter out the well-known libc and libstdc++ noise.

* '''ASan says "AddressSanitizer: DEADLYSIGNAL" with no obvious cause.''' Your program received a fatal signal (often SIGSEGV) inside ASan's own instrumentation. This usually means very serious memory corruption or stack overflow. Use <code>ASAN_OPTIONS=abort_on_error=1</code> to get a core dump and a clearer backtrace.

* '''Some sanitizer findings disappear at <code>-O2</code> or <code>-O3</code>.''' That is expected - the optimizer can eliminate the offending construct entirely. Keep your sanitizer build at <code>-O1</code>: optimized enough to be realistic, unoptimized enough to keep reports trustworthy.

== Looking ahead ==

Next week: '''Documentation as Code'''. You will add a Doxygen build to your CMake, publish the generated HTML docs as a GitLab Pages artifact, and turn your scattered code comments into navigable API documentation. Bring a piece of your capstone code that is poorly documented and you want to improve.

SDPT Lab 10

2026-05-18T13:50:45Z

Rhobincu:

= Week 10 Lab Activity: Documentation as Code with Doxygen =

== Objective ==

Generate API documentation for your Oven Controller with Doxygen and publish it automatically to GitLab Pages. This lab is deliberately short --- once the documentation pipeline works, the rest of the session is yours for capstone work.

== Background ==

Doxygen parses your source code and your specially-formatted comments and produces a cross-referenced HTML website. It is configured by a single file, the '''Doxyfile''', generated with <code>doxygen -g</code>. Because Doxygen reads source directly, it needs no compiled binary --- the documentation job does not depend on your <code>build</code> stage at all, and in this lab it runs <code>doxygen Doxyfile</code> directly without involving CMake. (You ''can'' add a <code>docs</code> target to <code>CMakeLists.txt</code> that wraps the same command, as the lecture notes, but this lab does not require it.)

GitLab Pages serves a static website straight from a CI job. On this course's instance, <code>gitlab.cs.pub.ro</code>, the Pages wildcard domain is <code>pages.upb.ro</code>. With unique domains enabled (the default), your published site receives an unpredictable URL of the form <code>https://<project>-<6-char-id>.pages.upb.ro/</code>. You read the exact URL from '''Deploy > Pages''' in the GitLab UI after the first successful deployment --- you cannot know it in advance.

The modern GitLab Pages CI syntax marks a job as a Pages job using a <code>pages:</code> property, and names the directory to publish using <code>publish:</code> inside it. The job itself can have any name. See the Week 10 lecture slide "CI Integration: Publishing to GitLab Pages" for the shape of this job.

For Doxygen comment syntax, see the lecture's before/after Oven Controller slides. Reference material: the Doxygen manual at https://www.doxygen.nl/manual/, and the special-command list at https://www.doxygen.nl/manual/commands.html.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Generate the Doxyfile.''' Run <code>doxygen -g</code> in your project root. This creates a file named <code>Doxyfile</code> containing every Doxygen setting with its default value and an explanatory comment. Commit it as-is in its own commit, so your later configuration changes are visible as a clean diff.

# '''Configure the Doxyfile.''' Edit at least the following settings: <code>PROJECT_NAME</code> and <code>PROJECT_NUMBER</code>; <code>INPUT</code> (point it at your source and header directories and your <code>README.md</code>); <code>RECURSIVE = YES</code>; <code>EXTRACT_ALL = YES</code>; <code>GENERATE_HTML = YES</code>; <code>GENERATE_LATEX = NO</code>; <code>HAVE_DOT = YES</code> (enables the Graphviz class and call diagrams); and <code>USE_MDFILE_AS_MAINPAGE</code> (set to your <code>README.md</code> so it becomes the documentation landing page). Leave <code>OUTPUT_DIRECTORY</code> empty and <code>HTML_OUTPUT</code> at its default <code>html</code>, so the generated site lands in <code>./html</code>.

# '''Document the Oven Controller's public API.''' Add Doxygen comments to the main class and its public methods. Each public function should have a <code>\brief</code>, plus <code>\param</code> and <code>\return</code> where they apply. Write genuine contracts --- units, valid ranges, error behavior --- not restatements of the function name. The lecture's before/after example sets the standard. ''This task is verified through your published documentation site, not submitted as a file.''

# '''Build and check locally.''' Run <code>doxygen Doxyfile</code>. Open <code>html/index.html</code> in a browser and confirm that your classes, your comments, and (if Graphviz is installed locally) the diagrams all appear as expected. Fix anything that looks wrong before moving on.

# '''Add the documentation job to CI.''' Edit <code>.gitlab-ci.yml</code>:
## Add a new <code>docs</code> stage as the last stage.
## Add a job (suggested name <code>create-pages</code>) in that stage. It should use a stock Debian or Ubuntu image, install <code>doxygen</code> and <code>graphviz</code> in a <code>before_script</code>, run <code>doxygen Doxyfile</code> in its <code>script</code>, and publish the <code>html</code> directory using the <code>pages:</code> property.
## Restrict the job to the default branch with a <code>rules:</code> entry, so the documentation deploys only from released code.

# '''Publish and verify.''' Push your branch and open the Merge Request. Note that because the job is restricted to the default branch, it will '''not''' run on your feature-branch pipeline --- this is expected. Once the MR is merged, the pipeline on the default branch runs the <code>create-pages</code> job. Then open '''Deploy > Pages''', find your site's live URL, open it, and confirm the documentation is served correctly. Paste that URL into your Merge Request description.

== Deliverables ==

Submit exactly two files:

# <code>Doxyfile</code> --- your configured Doxygen configuration file.
# <code>.gitlab-ci.yml</code> --- including the new <code>docs</code> stage and the <code>create-pages</code> job.

In addition, your Merge Request description must contain the live GitLab Pages URL from Task 6. The quality of your Doxygen comments (Task 3) is assessed by visiting that URL.

== Stretch tasks (optional) ==

Pick at most one. Neither earns extra points; both make your capstone documentation noticeably better.

* '''Turn documentation into a real gate.''' Set <code>EXTRACT_ALL = NO</code>, <code>WARN_IF_UNDOCUMENTED = YES</code>, and <code>WARN_AS_ERROR = YES</code> in your Doxyfile. Now Doxygen exits with an error --- failing the pipeline --- whenever a public entity has no documentation. Then document everything until the job passes. This is how documentation becomes a true quality gate rather than a suggestion.

* '''Add a hand-written architecture page.''' Create <code>docs/architecture.md</code> describing how the Oven Controller's pieces fit together. Add it to the Doxyfile's <code>INPUT</code>. It will appear as a first-class page in your documentation site, alongside the auto-extracted API reference.

== Common pitfalls ==

* '''The published site is 404 or shows the wrong content.''' The directory named in <code>publish:</code> must exactly match where Doxygen actually wrote the HTML. With the default <code>HTML_OUTPUT = html</code> and an empty <code>OUTPUT_DIRECTORY</code>, that directory is <code>html</code>. If you changed either setting, update <code>publish:</code> to match.

* '''The docs job never runs.''' If you restricted it to the default branch, it will not appear on feature-branch or Merge Request pipelines --- only after the merge. This is correct behavior. Verify the <code>doxygen</code> command itself locally (Task 4) so you are confident before merging.

* '''The <code>pages:</code> keyword causes a YAML or pipeline error.''' The Pages CI syntax has changed across GitLab versions. The <code>pages:</code> property with <code>publish:</code> inside it is the current form. If your instance rejects it, check the GitLab version of <code>gitlab.cs.pub.ro</code> and consult its documentation for the exact accepted syntax.

* '''No diagrams in the output.''' <code>HAVE_DOT = YES</code> requires the Graphviz <code>dot</code> tool to be installed. Make sure your CI <code>before_script</code> installs <code>graphviz</code>, not only <code>doxygen</code>.

* '''Doxygen reports warnings about undocumented members.''' With <code>EXTRACT_ALL = YES</code> this is harmless --- the site still builds. It only fails the job if you also set <code>WARN_AS_ERROR = YES</code> (see the stretch task).

* '''I cannot find my Pages URL.''' It is under '''Deploy > Pages''' in the GitLab project sidebar, and only appears after the <code>create-pages</code> job has succeeded at least once on the default branch.

== Looking ahead ==

Next week is the last: '''Capstone Synthesis'''. Your CI pipeline is now complete --- build, test, lint, sanitize, and docs. We step back, look at the whole system you have built, cover a few industry topics, and reserve lab time for capstone polish and a dry run of your project presentation.

SDPT Lab 10

2026-05-18T13:48:36Z

Rhobincu: Pagină nouă: = Week 10 Lab Activity: Documentation as Code with Doxygen = == Objective == Generate API documentation for your Oven Controller with Doxygen and publish it automatically to GitL...

= Week 10 Lab Activity: Documentation as Code with Doxygen =

== Objective ==

Generate API documentation for your Oven Controller with Doxygen and publish it automatically to GitLab Pages. This lab is deliberately short --- once the documentation pipeline works, the rest of the session is yours for capstone work.

== Background ==

Doxygen parses your source code and your specially-formatted comments and produces a cross-referenced HTML website. It is configured by a single file, the '''Doxyfile''', generated with <code>doxygen -g</code>. Because Doxygen reads source directly, it needs no compiled binary and no CMake involvement --- the documentation job is completely independent of your build.

GitLab Pages serves a static website straight from a CI job. On this course's instance, <code>gitlab.cs.pub.ro</code>, the Pages wildcard domain is <code>pages.upb.ro</code>. With unique domains enabled (the default), your published site receives an unpredictable URL of the form <code>https://<project>-<6-char-id>.pages.upb.ro/</code>. You read the exact URL from '''Deploy > Pages''' in the GitLab UI after the first successful deployment --- you cannot know it in advance.

The modern GitLab Pages CI syntax marks a job as a Pages job using a <code>pages:</code> property, and names the directory to publish using <code>publish:</code> inside it. The job itself can have any name. See the Week 10 lecture slide "CI Integration: Publishing to GitLab Pages" for the shape of this job.

For Doxygen comment syntax, see the lecture's before/after Oven Controller slides. Reference material: the Doxygen manual at https://www.doxygen.nl/manual/, and the special-command list at https://www.doxygen.nl/manual/commands.html.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Generate the Doxyfile.''' Run <code>doxygen -g</code> in your project root. This creates a file named <code>Doxyfile</code> containing every Doxygen setting with its default value and an explanatory comment. Commit it as-is in its own commit, so your later configuration changes are visible as a clean diff.

# '''Configure the Doxyfile.''' Edit at least the following settings: <code>PROJECT_NAME</code> and <code>PROJECT_NUMBER</code>; <code>INPUT</code> (point it at your source and header directories and your <code>README.md</code>); <code>RECURSIVE = YES</code>; <code>EXTRACT_ALL = YES</code>; <code>GENERATE_HTML = YES</code>; <code>GENERATE_LATEX = NO</code>; <code>HAVE_DOT = YES</code> (enables the Graphviz class and call diagrams); and <code>USE_MDFILE_AS_MAINPAGE</code> (set to your <code>README.md</code> so it becomes the documentation landing page). Leave <code>OUTPUT_DIRECTORY</code> empty and <code>HTML_OUTPUT</code> at its default <code>html</code>, so the generated site lands in <code>./html</code>.

# '''Document the Oven Controller's public API.''' Add Doxygen comments to the main class and its public methods. Each public function should have a <code>\brief</code>, plus <code>\param</code> and <code>\return</code> where they apply. Write genuine contracts --- units, valid ranges, error behavior --- not restatements of the function name. The lecture's before/after example sets the standard. ''This task is verified through your published documentation site, not submitted as a file.''

# '''Build and check locally.''' Run <code>doxygen Doxyfile</code>. Open <code>html/index.html</code> in a browser and confirm that your classes, your comments, and (if Graphviz is installed locally) the diagrams all appear as expected. Fix anything that looks wrong before moving on.

# '''Add the documentation job to CI.''' Edit <code>.gitlab-ci.yml</code>:
## Add a new <code>docs</code> stage as the last stage.
## Add a job (suggested name <code>create-pages</code>) in that stage. It should use a stock Debian or Ubuntu image, install <code>doxygen</code> and <code>graphviz</code> in a <code>before_script</code>, run <code>doxygen Doxyfile</code> in its <code>script</code>, and publish the <code>html</code> directory using the <code>pages:</code> property.
## Restrict the job to the default branch with a <code>rules:</code> entry, so the documentation deploys only from released code.

# '''Publish and verify.''' Push your branch and open the Merge Request. Note that because the job is restricted to the default branch, it will '''not''' run on your feature-branch pipeline --- this is expected. Once the MR is merged, the pipeline on the default branch runs the <code>create-pages</code> job. Then open '''Deploy > Pages''', find your site's live URL, open it, and confirm the documentation is served correctly. Paste that URL into your Merge Request description.

== Deliverables ==

Submit exactly two files:

# <code>Doxyfile</code> --- your configured Doxygen configuration file.
# <code>.gitlab-ci.yml</code> --- including the new <code>docs</code> stage and the <code>create-pages</code> job.

In addition, your Merge Request description must contain the live GitLab Pages URL from Task 6. The quality of your Doxygen comments (Task 3) is assessed by visiting that URL.

== Stretch tasks (optional) ==

Pick at most one. Neither earns extra points; both make your capstone documentation noticeably better.

* '''Turn documentation into a real gate.''' Set <code>EXTRACT_ALL = NO</code>, <code>WARN_IF_UNDOCUMENTED = YES</code>, and <code>WARN_AS_ERROR = YES</code> in your Doxyfile. Now Doxygen exits with an error --- failing the pipeline --- whenever a public entity has no documentation. Then document everything until the job passes. This is how documentation becomes a true quality gate rather than a suggestion.

* '''Add a hand-written architecture page.''' Create <code>docs/architecture.md</code> describing how the Oven Controller's pieces fit together. Add it to the Doxyfile's <code>INPUT</code>. It will appear as a first-class page in your documentation site, alongside the auto-extracted API reference.

== Common pitfalls ==

* '''The published site is 404 or shows the wrong content.''' The directory named in <code>publish:</code> must exactly match where Doxygen actually wrote the HTML. With the default <code>HTML_OUTPUT = html</code> and an empty <code>OUTPUT_DIRECTORY</code>, that directory is <code>html</code>. If you changed either setting, update <code>publish:</code> to match.

* '''The docs job never runs.''' If you restricted it to the default branch, it will not appear on feature-branch or Merge Request pipelines --- only after the merge. This is correct behavior. Verify the <code>doxygen</code> command itself locally (Task 4) so you are confident before merging.

* '''The <code>pages:</code> keyword causes a YAML or pipeline error.''' The Pages CI syntax has changed across GitLab versions. The <code>pages:</code> property with <code>publish:</code> inside it is the current form. If your instance rejects it, check the GitLab version of <code>gitlab.cs.pub.ro</code> and consult its documentation for the exact accepted syntax.

* '''No diagrams in the output.''' <code>HAVE_DOT = YES</code> requires the Graphviz <code>dot</code> tool to be installed. Make sure your CI <code>before_script</code> installs <code>graphviz</code>, not only <code>doxygen</code>.

* '''Doxygen reports warnings about undocumented members.''' With <code>EXTRACT_ALL = YES</code> this is harmless --- the site still builds. It only fails the job if you also set <code>WARN_AS_ERROR = YES</code> (see the stretch task).

* '''I cannot find my Pages URL.''' It is under '''Deploy > Pages''' in the GitLab project sidebar, and only appears after the <code>create-pages</code> job has succeeded at least once on the default branch.

== Looking ahead ==

Next week is the last: '''Capstone Synthesis'''. Your CI pipeline is now complete --- build, test, lint, sanitize, and docs. We step back, look at the whole system you have built, cover a few industry topics, and reserve lab time for capstone polish and a dry run of your project presentation.

Software Development Process and Testing

2026-05-18T13:48:30Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]
* [[SDPT Lab 3]]
* [[SDPT Lab 4]]
* [[SDPT Lab 5]]
* [[SDPT Lab 6]]
* [[SDPT Lab 7]]
* [[SDPT Lab 8]]
* [[SDPT Lab 9]]
* [[SDPT Lab 10]]

SDPT Lab 9

2026-05-11T13:41:55Z

Rhobincu: /* Deliverables */

= Week 9 Lab Activity: Dynamic Analysis with Sanitizers and Valgrind =

== Objective ==

Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</code> stage that builds the project under AddressSanitizer and UndefinedBehaviorSanitizer and runs your full test suite against the instrumented binary. By the end of this lab, your pipeline catches a fourth class of bug - runtime memory errors and undefined behavior - automatically on every push.

== Background ==

You will add a new CMake build type called <code>Sanitize</code> that compiles with <code>-fsanitize=address,undefined</code> alongside <code>-O1 -g -fno-omit-frame-pointer</code>. The <code>-O1</code> keeps the optimizer light enough that sanitizer reports stay readable; <code>-g</code> embeds debug information so backtraces have line numbers; <code>-fno-omit-frame-pointer</code> ensures those backtraces are actually complete on x86_64.

The sanitizers report errors by printing to stderr and exiting with a nonzero status. This means your existing GoogleTest tests do not need any modification: if a test triggers a sanitizer error, the test binary aborts, ctest reports failure, the CI job fails, and the MR is blocked. The pipeline plumbing from Week 6 carries this work for you for free.

In addition to the sanitizer build, you will run Valgrind manually once against the same codebase. The two tools are complementary: ASan is fast and runs in CI; Valgrind is slow but sometimes catches things ASan misses (notably uninitialized reads, which require MemorySanitizer to catch with sanitizers - and you saw in the lecture why MSan is impractical).

You will also reuse <code>gcovr</code> from Week 4. Dynamic analysis can only find bugs on code paths your tests actually execute, so coverage is part of the deliverable.

The point of this lab is not to introduce new tools you have never seen - you have met all four (ASan/UBSan/Valgrind/gcovr) in lectures. The point is to wire them together into your existing pipeline and prove the wiring works by deliberately breaking things.

Documentation pointers: <code>man valgrind</code>, the AddressSanitizer wiki at https://github.com/google/sanitizers/wiki/AddressSanitizer, the UBSan documentation at https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html, and your existing gcovr docs.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Extend the Docker build environment.''' Update your <code>Dockerfile</code> to install <code>valgrind</code> alongside the tools already present. Rebuild and verify with <code>valgrind --version</code>. The sanitizers themselves ship with the compiler, so no separate package is needed - but confirm by running <code>echo "int main(){}" | g++ -fsanitize=address -x c++ - -o /dev/null</code> inside the container; if that succeeds, ASan is available.

# '''Add the Sanitize build type to CMake.''' In your <code>CMakeLists.txt</code>, add logic that, when <code>CMAKE_BUILD_TYPE</code> equals <code>Sanitize</code>, sets compile and link options for <code>-fsanitize=address,undefined</code> plus <code>-O1 -g -fno-omit-frame-pointer</code>. Make sure both compile ''and'' link options include the sanitizer flag - if you forget the link side, you will get cryptic linker errors about missing <code>__asan_*</code> symbols. Test locally: <code>cmake -B build-san -DCMAKE_BUILD_TYPE=Sanitize</code>, then build, then run a test binary directly to confirm it produces output that mentions ASan.

# '''Run your existing tests under the sanitizers and clean up.''' Run <code>ctest --test-dir build-san --output-on-failure</code>. If any tests fail due to sanitizer reports, fix the underlying bugs in the Oven Controller code (do '''not''' suppress them). Typical findings in EE-trained codebases: forgotten <code>delete[]</code>, signed overflow in temperature math, reading from a member variable that was never initialized in a constructor. Each fix should be its own small commit with a message describing what the sanitizer reported.

# '''Add a sanitize stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>sanitize</code> stage after <code>test</code>. The job should: configure a <code>Sanitize</code> build, compile it, and run <code>ctest</code> against it. Use your existing Docker image. The job must fail the pipeline on any sanitizer error.

# '''Trigger ASan on purpose.''' On your feature branch, introduce a deliberate '''heap-buffer-overflow''' bug somewhere in the production code. Push, watch the <code>sanitize</code> stage fail, capture the ASan report (the job-log permalink in the MR description is sufficient), then revert. Your goal is to see the full ASan diagnostic - the line with the offending access, the line of the allocation, and the "stack-buffer-overflow" or "heap-buffer-overflow" classification.

# '''Trigger UBSan on purpose.''' Repeat with a deliberate '''signed integer overflow''' or '''null pointer dereference'''. The UBSan report looks different from ASan's - a one-line "runtime error" message at the trigger point. Capture, revert.

# '''Trigger LeakSanitizer on purpose.''' Repeat with a deliberate memory leak (allocate something on the heap, do not free it). LeakSan reports at program exit, not at the leak site. Capture, revert.

# '''Run Valgrind once, manually.''' Build your project in a normal Debug configuration (no sanitizers - they conflict with Valgrind's instrumentation). From inside your Docker container, run <code>valgrind --leak-check=full --show-leakkinds=all --track-origins=yes ./your_test_binary</code>. Save the full output. If Valgrind reports any errors that ASan did not, fix them. Add a paragraph to your MR description noting which tool caught what, or that the two agreed completely.

# '''Re-check coverage.''' Recall from Week 4: <code>gcovr -r .. --html-details</code> against a coverage-instrumented build. Generate a current coverage report. Compare against your Week 4 baseline. If coverage dropped, write enough additional tests to bring it back. Coverage gaps are places where sanitizer findings are silently impossible, so this is part of the dynamic-analysis story even if the tool is the same one you used in Week 4.

# '''Document the cost.''' Compare the wall-clock time of your full pipeline before and after this lab. The <code>sanitize</code> stage adds work; document by how much in your MR description. As in Week 7, "the sanitize stage adds 6 minutes and we caught two real bugs" is a more honest finding than rounding to "negligible".

# '''Review and merge.''' Open the MR. The reviewer should check: the Sanitize build type works locally and in CI, that the three deliberate-bug pipeline runs are visible, that the Valgrind output is referenced in the MR, that coverage has not regressed.

== Stretch tasks (optional, if you finish early) ==

Pick at most one. None earn extra points; all teach you something useful.

* '''Add a second sanitizer build.''' Some teams maintain two CI jobs: one with ASan+UBSan, one with ThreadSanitizer. Add a TSan job that builds with <code>-fsanitize=thread</code> and runs the tests. Even on single-threaded code this is harmless, and it sets you up for the day you add concurrency.

* '''Valgrind in CI.''' Add a manual-trigger CI job (using GitLab's <code>when: manual</code>) that runs Valgrind on your test binary. It is too slow to run on every push, but a one-click button for the weekly deep audit is valuable.

* '''Coverage threshold gate.''' Use <code>gcovr --fail-under-line N</code> to fail the pipeline if line coverage drops below a threshold you choose (e.g. 80%). Now coverage is also an automatic quality gate, not just a number.

* '''Sanitizer-specific environment variables.''' Read the docs for <code>ASAN_OPTIONS</code> and <code>UBSAN_OPTIONS</code>. Add <code>halt_on_error=1</code> and <code>abort_on_error=1</code> to your CI environment, which makes the first error a hard stop instead of letting the program limp on. Useful for getting clearer reports.

== Deliverables ==

For this lab to be considered complete, your <code>main</code> branch must contain:

# A <code>Dockerfile</code> that installs <code>valgrind</code> in addition to the previous week's tooling.
# A <code>CMakeLists.txt</code> with a working <code>Sanitize</code> build type.
# A <code>.gitlab-ci.yml</code> with a <code>sanitize</code> stage running after the <code>test</code> stage.
# A merged Merge Request whose linked Issue (or MR description) contains:
## References to '''three''' failed pipeline runs from Tasks 5, 6, and 7 (one each for ASan, UBSan, and LeakSan), with the relevant snippet of each sanitizer's report quoted briefly.
## The Valgrind output from Task 8, or a permalink to it (a job artifact or a gist).
## A note comparing Valgrind's findings with the sanitizers' findings (Task 8).
## The coverage comparison from Task 9 (before/after, plus what you did about it).
## The pipeline cost comparison from Task 10.

The VPL deliverables include the first three files which will be the only ones graded.

== Common pitfalls ==

* '''Linker errors mentioning <code>__asan_*</code> or <code>__ubsan_*</code> symbols.''' You set the sanitizer flag for compilation but forgot to also pass it at the link step. In CMake, both <code>add_compile_options</code> and <code>add_link_options</code> need <code>-fsanitize=...</code>.

* '''Sanitizers and Valgrind conflict.''' You cannot run a sanitizer-built binary under Valgrind. They both rely on intercepting memory accesses and the interception clashes. Build a separate Debug binary (no sanitizers) when you want to run Valgrind.

* '''ASan reports look truncated or have <code>??</code> in the backtrace.''' Almost always means missing <code>-g</code> or missing <code>-fno-omit-frame-pointer</code>. Without frame pointers, the unwinder on x86_64 falls back to imperfect heuristics.

* '''The pipeline passes locally but ASan errors only appear in CI.''' Check that your container image is using a recent enough compiler. GCC's ASan got significantly better between 8.x and 11.x; UBSan added several checks in the same span. The Debian Bookworm <code>g++</code> (12.x) is fine.

* '''Tests pass under the sanitizers locally, but a teammate's machine shows different errors.''' ASan and UBSan are deterministic for a given binary, but slight platform differences (libc version, glibc malloc settings) can occasionally surface bugs that are real but only fire on one machine. The CI container is the source of truth.

* '''Valgrind reports complaints in the standard library.''' Usually you can ignore these unless they reference your own code. Use <code>--suppressions=/usr/share/valgrind/default.supp</code> (most distributions ship a default suppression file) to filter out the well-known libc and libstdc++ noise.

* '''ASan says "AddressSanitizer: DEADLYSIGNAL" with no obvious cause.''' Your program received a fatal signal (often SIGSEGV) inside ASan's own instrumentation. This usually means very serious memory corruption or stack overflow. Use <code>ASAN_OPTIONS=abort_on_error=1</code> to get a core dump and a clearer backtrace.

* '''Some sanitizer findings disappear at <code>-O2</code> or <code>-O3</code>.''' That is expected - the optimizer can eliminate the offending construct entirely. Keep your sanitizer build at <code>-O1</code>: optimized enough to be realistic, unoptimized enough to keep reports trustworthy.

== Looking ahead ==

Next week: '''Documentation as Code'''. You will add a Doxygen build to your CMake, publish the generated HTML docs as a GitLab Pages artifact, and turn your scattered code comments into navigable API documentation. Bring a piece of your capstone code that is poorly documented and you want to improve.

SDPT Lab 9

2026-05-11T13:34:01Z

Rhobincu:

= Week 9 Lab Activity: Dynamic Analysis with Sanitizers and Valgrind =

== Objective ==

Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</code> stage that builds the project under AddressSanitizer and UndefinedBehaviorSanitizer and runs your full test suite against the instrumented binary. By the end of this lab, your pipeline catches a fourth class of bug - runtime memory errors and undefined behavior - automatically on every push.

== Background ==

You will add a new CMake build type called <code>Sanitize</code> that compiles with <code>-fsanitize=address,undefined</code> alongside <code>-O1 -g -fno-omit-frame-pointer</code>. The <code>-O1</code> keeps the optimizer light enough that sanitizer reports stay readable; <code>-g</code> embeds debug information so backtraces have line numbers; <code>-fno-omit-frame-pointer</code> ensures those backtraces are actually complete on x86_64.

The sanitizers report errors by printing to stderr and exiting with a nonzero status. This means your existing GoogleTest tests do not need any modification: if a test triggers a sanitizer error, the test binary aborts, ctest reports failure, the CI job fails, and the MR is blocked. The pipeline plumbing from Week 6 carries this work for you for free.

In addition to the sanitizer build, you will run Valgrind manually once against the same codebase. The two tools are complementary: ASan is fast and runs in CI; Valgrind is slow but sometimes catches things ASan misses (notably uninitialized reads, which require MemorySanitizer to catch with sanitizers - and you saw in the lecture why MSan is impractical).

You will also reuse <code>gcovr</code> from Week 4. Dynamic analysis can only find bugs on code paths your tests actually execute, so coverage is part of the deliverable.

The point of this lab is not to introduce new tools you have never seen - you have met all four (ASan/UBSan/Valgrind/gcovr) in lectures. The point is to wire them together into your existing pipeline and prove the wiring works by deliberately breaking things.

Documentation pointers: <code>man valgrind</code>, the AddressSanitizer wiki at https://github.com/google/sanitizers/wiki/AddressSanitizer, the UBSan documentation at https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html, and your existing gcovr docs.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Extend the Docker build environment.''' Update your <code>Dockerfile</code> to install <code>valgrind</code> alongside the tools already present. Rebuild and verify with <code>valgrind --version</code>. The sanitizers themselves ship with the compiler, so no separate package is needed - but confirm by running <code>echo "int main(){}" | g++ -fsanitize=address -x c++ - -o /dev/null</code> inside the container; if that succeeds, ASan is available.

# '''Add the Sanitize build type to CMake.''' In your <code>CMakeLists.txt</code>, add logic that, when <code>CMAKE_BUILD_TYPE</code> equals <code>Sanitize</code>, sets compile and link options for <code>-fsanitize=address,undefined</code> plus <code>-O1 -g -fno-omit-frame-pointer</code>. Make sure both compile ''and'' link options include the sanitizer flag - if you forget the link side, you will get cryptic linker errors about missing <code>__asan_*</code> symbols. Test locally: <code>cmake -B build-san -DCMAKE_BUILD_TYPE=Sanitize</code>, then build, then run a test binary directly to confirm it produces output that mentions ASan.

# '''Run your existing tests under the sanitizers and clean up.''' Run <code>ctest --test-dir build-san --output-on-failure</code>. If any tests fail due to sanitizer reports, fix the underlying bugs in the Oven Controller code (do '''not''' suppress them). Typical findings in EE-trained codebases: forgotten <code>delete[]</code>, signed overflow in temperature math, reading from a member variable that was never initialized in a constructor. Each fix should be its own small commit with a message describing what the sanitizer reported.

# '''Add a sanitize stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>sanitize</code> stage after <code>test</code>. The job should: configure a <code>Sanitize</code> build, compile it, and run <code>ctest</code> against it. Use your existing Docker image. The job must fail the pipeline on any sanitizer error.

# '''Trigger ASan on purpose.''' On your feature branch, introduce a deliberate '''heap-buffer-overflow''' bug somewhere in the production code. Push, watch the <code>sanitize</code> stage fail, capture the ASan report (the job-log permalink in the MR description is sufficient), then revert. Your goal is to see the full ASan diagnostic - the line with the offending access, the line of the allocation, and the "stack-buffer-overflow" or "heap-buffer-overflow" classification.

# '''Trigger UBSan on purpose.''' Repeat with a deliberate '''signed integer overflow''' or '''null pointer dereference'''. The UBSan report looks different from ASan's - a one-line "runtime error" message at the trigger point. Capture, revert.

# '''Trigger LeakSanitizer on purpose.''' Repeat with a deliberate memory leak (allocate something on the heap, do not free it). LeakSan reports at program exit, not at the leak site. Capture, revert.

# '''Run Valgrind once, manually.''' Build your project in a normal Debug configuration (no sanitizers - they conflict with Valgrind's instrumentation). From inside your Docker container, run <code>valgrind --leak-check=full --show-leakkinds=all --track-origins=yes ./your_test_binary</code>. Save the full output. If Valgrind reports any errors that ASan did not, fix them. Add a paragraph to your MR description noting which tool caught what, or that the two agreed completely.

# '''Re-check coverage.''' Recall from Week 4: <code>gcovr -r .. --html-details</code> against a coverage-instrumented build. Generate a current coverage report. Compare against your Week 4 baseline. If coverage dropped, write enough additional tests to bring it back. Coverage gaps are places where sanitizer findings are silently impossible, so this is part of the dynamic-analysis story even if the tool is the same one you used in Week 4.

# '''Document the cost.''' Compare the wall-clock time of your full pipeline before and after this lab. The <code>sanitize</code> stage adds work; document by how much in your MR description. As in Week 7, "the sanitize stage adds 6 minutes and we caught two real bugs" is a more honest finding than rounding to "negligible".

# '''Review and merge.''' Open the MR. The reviewer should check: the Sanitize build type works locally and in CI, that the three deliberate-bug pipeline runs are visible, that the Valgrind output is referenced in the MR, that coverage has not regressed.

== Stretch tasks (optional, if you finish early) ==

Pick at most one. None earn extra points; all teach you something useful.

* '''Add a second sanitizer build.''' Some teams maintain two CI jobs: one with ASan+UBSan, one with ThreadSanitizer. Add a TSan job that builds with <code>-fsanitize=thread</code> and runs the tests. Even on single-threaded code this is harmless, and it sets you up for the day you add concurrency.

* '''Valgrind in CI.''' Add a manual-trigger CI job (using GitLab's <code>when: manual</code>) that runs Valgrind on your test binary. It is too slow to run on every push, but a one-click button for the weekly deep audit is valuable.

* '''Coverage threshold gate.''' Use <code>gcovr --fail-under-line N</code> to fail the pipeline if line coverage drops below a threshold you choose (e.g. 80%). Now coverage is also an automatic quality gate, not just a number.

* '''Sanitizer-specific environment variables.''' Read the docs for <code>ASAN_OPTIONS</code> and <code>UBSAN_OPTIONS</code>. Add <code>halt_on_error=1</code> and <code>abort_on_error=1</code> to your CI environment, which makes the first error a hard stop instead of letting the program limp on. Useful for getting clearer reports.

== Deliverables ==

For this lab to be marked complete, your <code>main</code> branch must contain:

# A <code>Dockerfile</code> that installs <code>valgrind</code> in addition to the previous week's tooling.
# A <code>CMakeLists.txt</code> with a working <code>Sanitize</code> build type.
# A <code>.gitlab-ci.yml</code> with a <code>sanitize</code> stage running after the <code>test</code> stage.
# A merged Merge Request whose linked Issue (or MR description) contains:
## References to '''three''' failed pipeline runs from Tasks 5, 6, and 7 (one each for ASan, UBSan, and LeakSan), with the relevant snippet of each sanitizer's report quoted briefly.
## The Valgrind output from Task 8, or a permalink to it (a job artifact or a gist).
## A note comparing Valgrind's findings with the sanitizers' findings (Task 8).
## The coverage comparison from Task 9 (before/after, plus what you did about it).
## The pipeline cost comparison from Task 10.

== Common pitfalls ==

* '''Linker errors mentioning <code>__asan_*</code> or <code>__ubsan_*</code> symbols.''' You set the sanitizer flag for compilation but forgot to also pass it at the link step. In CMake, both <code>add_compile_options</code> and <code>add_link_options</code> need <code>-fsanitize=...</code>.

* '''Sanitizers and Valgrind conflict.''' You cannot run a sanitizer-built binary under Valgrind. They both rely on intercepting memory accesses and the interception clashes. Build a separate Debug binary (no sanitizers) when you want to run Valgrind.

* '''ASan reports look truncated or have <code>??</code> in the backtrace.''' Almost always means missing <code>-g</code> or missing <code>-fno-omit-frame-pointer</code>. Without frame pointers, the unwinder on x86_64 falls back to imperfect heuristics.

* '''The pipeline passes locally but ASan errors only appear in CI.''' Check that your container image is using a recent enough compiler. GCC's ASan got significantly better between 8.x and 11.x; UBSan added several checks in the same span. The Debian Bookworm <code>g++</code> (12.x) is fine.

* '''Tests pass under the sanitizers locally, but a teammate's machine shows different errors.''' ASan and UBSan are deterministic for a given binary, but slight platform differences (libc version, glibc malloc settings) can occasionally surface bugs that are real but only fire on one machine. The CI container is the source of truth.

* '''Valgrind reports complaints in the standard library.''' Usually you can ignore these unless they reference your own code. Use <code>--suppressions=/usr/share/valgrind/default.supp</code> (most distributions ship a default suppression file) to filter out the well-known libc and libstdc++ noise.

* '''ASan says "AddressSanitizer: DEADLYSIGNAL" with no obvious cause.''' Your program received a fatal signal (often SIGSEGV) inside ASan's own instrumentation. This usually means very serious memory corruption or stack overflow. Use <code>ASAN_OPTIONS=abort_on_error=1</code> to get a core dump and a clearer backtrace.

* '''Some sanitizer findings disappear at <code>-O2</code> or <code>-O3</code>.''' That is expected - the optimizer can eliminate the offending construct entirely. Keep your sanitizer build at <code>-O1</code>: optimized enough to be realistic, unoptimized enough to keep reports trustworthy.

== Looking ahead ==

Next week: '''Documentation as Code'''. You will add a Doxygen build to your CMake, publish the generated HTML docs as a GitLab Pages artifact, and turn your scattered code comments into navigable API documentation. Bring a piece of your capstone code that is poorly documented and you want to improve.

SDPT Lab 9

2026-05-11T13:33:13Z

Rhobincu: Pagină nouă: = Week 9 Lab Activity: Dynamic Analysis with Sanitizers and Valgrind = == Objective == Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</cod...

= Week 9 Lab Activity: Dynamic Analysis with Sanitizers and Valgrind =

== Objective ==

Extend your Oven Controller's CI pipeline with a fourth quality gate: a <code>sanitize</code> stage that builds the project under AddressSanitizer and UndefinedBehaviorSanitizer and runs your full test suite against the instrumented binary. By the end of this lab, your pipeline catches a fourth class of bug --- runtime memory errors and undefined behavior --- automatically on every push.

== Background ==

You will add a new CMake build type called <code>Sanitize</code> that compiles with <code>-fsanitize=address,undefined</code> alongside <code>-O1 -g -fno-omit-frame-pointer</code>. The <code>-O1</code> keeps the optimizer light enough that sanitizer reports stay readable; <code>-g</code> embeds debug information so backtraces have line numbers; <code>-fno-omit-frame-pointer</code> ensures those backtraces are actually complete on x86_64.

The sanitizers report errors by printing to stderr and exiting with a nonzero status. This means your existing GoogleTest tests do not need any modification: if a test triggers a sanitizer error, the test binary aborts, ctest reports failure, the CI job fails, and the MR is blocked. The pipeline plumbing from Week 6 carries this work for you for free.

In addition to the sanitizer build, you will run Valgrind manually once against the same codebase. The two tools are complementary: ASan is fast and runs in CI; Valgrind is slow but sometimes catches things ASan misses (notably uninitialized reads, which require MemorySanitizer to catch with sanitizers --- and you saw in the lecture why MSan is impractical).

You will also reuse <code>gcovr</code> from Week 4. Dynamic analysis can only find bugs on code paths your tests actually execute, so coverage is part of the deliverable.

The point of this lab is not to introduce new tools you have never seen --- you have met all four (ASan/UBSan/Valgrind/gcovr) in lectures. The point is to wire them together into your existing pipeline and prove the wiring works by deliberately breaking things.

Documentation pointers: <code>man valgrind</code>, the AddressSanitizer wiki at https://github.com/google/sanitizers/wiki/AddressSanitizer, the UBSan documentation at https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html, and your existing gcovr docs.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Extend the Docker build environment.''' Update your <code>Dockerfile</code> to install <code>valgrind</code> alongside the tools already present. Rebuild and verify with <code>valgrind --version</code>. The sanitizers themselves ship with the compiler, so no separate package is needed --- but confirm by running <code>echo "int main(){}" | g++ -fsanitize=address -x c++ - -o /dev/null</code> inside the container; if that succeeds, ASan is available.

# '''Add the Sanitize build type to CMake.''' In your <code>CMakeLists.txt</code>, add logic that, when <code>CMAKE_BUILD_TYPE</code> equals <code>Sanitize</code>, sets compile and link options for <code>-fsanitize=address,undefined</code> plus <code>-O1 -g -fno-omit-frame-pointer</code>. Make sure both compile ''and'' link options include the sanitizer flag --- if you forget the link side, you will get cryptic linker errors about missing <code>__asan_*</code> symbols. Test locally: <code>cmake -B build-san -DCMAKE_BUILD_TYPE=Sanitize</code>, then build, then run a test binary directly to confirm it produces output that mentions ASan.

# '''Run your existing tests under the sanitizers and clean up.''' Run <code>ctest --test-dir build-san --output-on-failure</code>. If any tests fail due to sanitizer reports, fix the underlying bugs in the Oven Controller code (do '''not''' suppress them). Typical findings in EE-trained codebases: forgotten <code>delete[]</code>, signed overflow in temperature math, reading from a member variable that was never initialized in a constructor. Each fix should be its own small commit with a message describing what the sanitizer reported.

# '''Add a sanitize stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>sanitize</code> stage after <code>test</code>. The job should: configure a <code>Sanitize</code> build, compile it, and run <code>ctest</code> against it. Use your existing Docker image. The job must fail the pipeline on any sanitizer error.

# '''Trigger ASan on purpose.''' On your feature branch, introduce a deliberate '''heap-buffer-overflow''' bug somewhere in the production code. Push, watch the <code>sanitize</code> stage fail, capture the ASan report (the job-log permalink in the MR description is sufficient), then revert. Your goal is to see the full ASan diagnostic --- the line with the offending access, the line of the allocation, and the "stack-buffer-overflow" or "heap-buffer-overflow" classification.

# '''Trigger UBSan on purpose.''' Repeat with a deliberate '''signed integer overflow''' or '''null pointer dereference'''. The UBSan report looks different from ASan's --- a one-line "runtime error" message at the trigger point. Capture, revert.

# '''Trigger LeakSanitizer on purpose.''' Repeat with a deliberate memory leak (allocate something on the heap, do not free it). LeakSan reports at program exit, not at the leak site. Capture, revert.

# '''Run Valgrind once, manually.''' Build your project in a normal Debug configuration (no sanitizers --- they conflict with Valgrind's instrumentation). From inside your Docker container, run <code>valgrind --leak-check=full --show-leakkinds=all --track-origins=yes ./your_test_binary</code>. Save the full output. If Valgrind reports any errors that ASan did not, fix them. Add a paragraph to your MR description noting which tool caught what, or that the two agreed completely.

# '''Re-check coverage.''' Recall from Week 4: <code>gcovr -r .. --html-details</code> against a coverage-instrumented build. Generate a current coverage report. Compare against your Week 4 baseline. If coverage dropped, write enough additional tests to bring it back. Coverage gaps are places where sanitizer findings are silently impossible, so this is part of the dynamic-analysis story even if the tool is the same one you used in Week 4.

# '''Document the cost.''' Compare the wall-clock time of your full pipeline before and after this lab. The <code>sanitize</code> stage adds work; document by how much in your MR description. As in Week 7, "the sanitize stage adds 6 minutes and we caught two real bugs" is a more honest finding than rounding to "negligible".

# '''Review and merge.''' Open the MR. The reviewer should check: the Sanitize build type works locally and in CI, that the three deliberate-bug pipeline runs are visible, that the Valgrind output is referenced in the MR, that coverage has not regressed.

== Stretch tasks (optional, if you finish early) ==

Pick at most one. None earn extra points; all teach you something useful.

* '''Add a second sanitizer build.''' Some teams maintain two CI jobs: one with ASan+UBSan, one with ThreadSanitizer. Add a TSan job that builds with <code>-fsanitize=thread</code> and runs the tests. Even on single-threaded code this is harmless, and it sets you up for the day you add concurrency.

* '''Valgrind in CI.''' Add a manual-trigger CI job (using GitLab's <code>when: manual</code>) that runs Valgrind on your test binary. It is too slow to run on every push, but a one-click button for the weekly deep audit is valuable.

* '''Coverage threshold gate.''' Use <code>gcovr --fail-under-line N</code> to fail the pipeline if line coverage drops below a threshold you choose (e.g. 80%). Now coverage is also an automatic quality gate, not just a number.

* '''Sanitizer-specific environment variables.''' Read the docs for <code>ASAN_OPTIONS</code> and <code>UBSAN_OPTIONS</code>. Add <code>halt_on_error=1</code> and <code>abort_on_error=1</code> to your CI environment, which makes the first error a hard stop instead of letting the program limp on. Useful for getting clearer reports.

== Deliverables ==

For this lab to be marked complete, your <code>main</code> branch must contain:

# A <code>Dockerfile</code> that installs <code>valgrind</code> in addition to the previous week's tooling.
# A <code>CMakeLists.txt</code> with a working <code>Sanitize</code> build type.
# A <code>.gitlab-ci.yml</code> with a <code>sanitize</code> stage running after the <code>test</code> stage.
# A merged Merge Request whose linked Issue (or MR description) contains:
## References to '''three''' failed pipeline runs from Tasks 5, 6, and 7 (one each for ASan, UBSan, and LeakSan), with the relevant snippet of each sanitizer's report quoted briefly.
## The Valgrind output from Task 8, or a permalink to it (a job artifact or a gist).
## A note comparing Valgrind's findings with the sanitizers' findings (Task 8).
## The coverage comparison from Task 9 (before/after, plus what you did about it).
## The pipeline cost comparison from Task 10.

== Common pitfalls ==

* '''Linker errors mentioning <code>__asan_*</code> or <code>__ubsan_*</code> symbols.''' You set the sanitizer flag for compilation but forgot to also pass it at the link step. In CMake, both <code>add_compile_options</code> and <code>add_link_options</code> need <code>-fsanitize=...</code>.

* '''Sanitizers and Valgrind conflict.''' You cannot run a sanitizer-built binary under Valgrind. They both rely on intercepting memory accesses and the interception clashes. Build a separate Debug binary (no sanitizers) when you want to run Valgrind.

* '''ASan reports look truncated or have <code>??</code> in the backtrace.''' Almost always means missing <code>-g</code> or missing <code>-fno-omit-frame-pointer</code>. Without frame pointers, the unwinder on x86_64 falls back to imperfect heuristics.

* '''The pipeline passes locally but ASan errors only appear in CI.''' Check that your container image is using a recent enough compiler. GCC's ASan got significantly better between 8.x and 11.x; UBSan added several checks in the same span. The Debian Bookworm <code>g++</code> (12.x) is fine.

* '''Tests pass under the sanitizers locally, but a teammate's machine shows different errors.''' ASan and UBSan are deterministic for a given binary, but slight platform differences (libc version, glibc malloc settings) can occasionally surface bugs that are real but only fire on one machine. The CI container is the source of truth.

* '''Valgrind reports complaints in the standard library.''' Usually you can ignore these unless they reference your own code. Use <code>--suppressions=/usr/share/valgrind/default.supp</code> (most distributions ship a default suppression file) to filter out the well-known libc and libstdc++ noise.

* '''ASan says "AddressSanitizer: DEADLYSIGNAL" with no obvious cause.''' Your program received a fatal signal (often SIGSEGV) inside ASan's own instrumentation. This usually means very serious memory corruption or stack overflow. Use <code>ASAN_OPTIONS=abort_on_error=1</code> to get a core dump and a clearer backtrace.

* '''Some sanitizer findings disappear at <code>-O2</code> or <code>-O3</code>.''' That is expected --- the optimizer can eliminate the offending construct entirely. Keep your sanitizer build at <code>-O1</code>: optimized enough to be realistic, unoptimized enough to keep reports trustworthy.

== Looking ahead ==

Next week: '''Documentation as Code'''. You will add a Doxygen build to your CMake, publish the generated HTML docs as a GitLab Pages artifact, and turn your scattered code comments into navigable API documentation. Bring a piece of your capstone code that is poorly documented and you want to improve.

Software Development Process and Testing

2026-05-11T13:33:07Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]
* [[SDPT Lab 3]]
* [[SDPT Lab 4]]
* [[SDPT Lab 5]]
* [[SDPT Lab 6]]
* [[SDPT Lab 7]]
* [[SDPT Lab 8]]
* [[SDPT Lab 9]]

SDPT Lab 8

2026-05-04T13:34:48Z

Rhobincu: Pagină nouă: = Week 8 Lab Activity: Networking, Security, and VPNs = == Objective == Bring up two VMs that you fully control --- one acting as the server, one as an ARM-based ''edge device''...

= Week 8 Lab Activity: Networking, Security, and VPNs =

== Objective ==

Bring up two VMs that you fully control --- one acting as the server, one as an ARM-based ''edge device'' --- and use them to practice the techniques from this week's lecture: a raw TCP echo, an HTTP/REST exchange, a TLS-protected version of the same, and a three-peer WireGuard mesh that stitches your laptop and both VMs into one private encrypted overlay network.

This lab is allowed to run longer than your usual 1h50min. Plan for roughly 2h30min if you have not used QEMU before.

== Background ==

=== Why two VMs ===

Your capstone has two physical machines (a Pi and a server VM). For this lab you do not have a Pi, so you will emulate one with QEMU running an ARM64 Debian image. This has two pedagogical benefits: you practice exactly the cross-architecture work that production embedded developers do, and you get a self-contained environment that does not depend on lab hardware or shared infrastructure.

=== Choosing your virtualization stack ===

You have several options for running VMs on your laptop. Each has tradeoffs that matter for this lab.

'''VirtualBox + QEMU mixed.''' The most common student instinct is to use VirtualBox (familiar GUI) for the x86 VM and QEMU for the ARM VM. This is the option to ''avoid''. On Windows, VirtualBox 7.x technically coexists with QEMU's WHPX accelerator, but the two compete for the same hypervisor primitives and you will see strange failures (slow boots, network glitches, occasional VM crashes) that are extremely hard to diagnose mid-lab.

'''KVM (Linux native).''' If your laptop runs Linux, KVM is built into the kernel and gives you near-native VM speed for x86 guests. ARM guests still run under TCG (software emulation) since you are emulating a different architecture. This is the cleanest option if it is available to you.

'''QEMU on Windows with WHPX.''' QEMU runs natively on Windows. For x86 guests it can use Microsoft's WHPX accelerator, giving acceptable performance. ''But'' WHPX only accelerates same-architecture virtualization, so your ARM VM will boot in software emulation: functional, but slow (5--10 minutes to first login).

'''WSL2 on Windows.''' Run everything inside WSL2 and treat your machine as a Linux host. This works well, requires a one-time WSL2 setup, and lets you follow the Linux instructions verbatim. Best Windows option if you are willing to set up WSL2.

'''QEMU on macOS with HVF.''' QEMU on macOS can use the Hypervisor.framework accelerator (`-accel hvf`) for x86 guests. ARM guests use TCG. Apple Silicon Macs are an interesting case: the ARM VM is actually ''faster'' than the x86 VM, because ARM is the native architecture. Adjust the architecture flags accordingly.

'''Recommendation for this lab: QEMU for both VMs, on whatever host OS you have.''' One tool, one set of quirks, one mental model. The setup tutorial below uses QEMU exclusively.

=== Networking the two VMs ===

QEMU offers two relevant networking modes. '''User-mode networking''' (`-net user` or `-netdev user`) is the default: simple, requires no permissions, but the VMs cannot directly address each other --- they each see a private NAT'd network. Useful for outbound-only traffic (apt-get, ssh ''into'' the VM via port-forwarding), useless for "VM A talks to VM B".

'''TAP-based bridged networking''' (`-netdev tap`) gives each VM a real-looking interface on a software bridge on the host. The VMs can address each other directly using their bridge IPs. This is what we need. On Linux it requires a `bridge-utils` setup (15 minutes once); on Windows it requires installing the OpenVPN TAP driver and is fiddlier; on macOS it is well-supported.

For the lab, we will use a third hybrid option that works the same on all platforms: '''each VM uses user-mode networking to reach the internet, plus a second `socket` interface that connects the two VMs directly'''. This is QEMU's `-netdev socket` feature: one VM listens on a TCP port, the other connects to it, and to both guests it looks like a normal network interface. No bridge, no admin permissions, no platform-specific drivers.

=== The cpp-httplib library ===

Single-header HTTP server and client at https://github.com/yhirose/cpp-httplib. Drop `httplib.h` next to your code, `#include` it, you have HTTP. With `-DCPPHTTPLIB_OPENSSL_SUPPORT` and OpenSSL installed, the same library gives you HTTPS via `httplib::SSLServer` and `httplib::SSLClient`. For JSON, use https://github.com/nlohmann/json (also single-header).

=== WireGuard ===

WireGuard is in the Linux kernel since 5.6. Configuration is one short text file per peer. Each peer has a public/private keypair generated with `wg genkey | tee privatekey | wg pubkey > publickey`. Each peer's config lists the other peers' public keys and which IPs to expect from each. Useful references: `man wg`, `man wg-quick`, https://www.wireguard.com/quickstart/.

=== Wireshark ===

The standard packet inspection tool. Useful filters for this lab: `tcp.port == 9000`, `http`, `tls`, `udp.port == 51820`. ''Tip:'' to capture traffic between two QEMU VMs that talk over a `socket` interface, capture on the loopback interface of your host (since QEMU's socket netdev tunnels through host TCP).

== Setup tutorial: bringing up the two VMs ==

Allocate roughly 20--30 minutes for this section. Read through it once before typing.

=== Step S1: install QEMU ===

* Linux (Debian/Ubuntu): `sudo apt install qemu-system-x86 qemu-system-arm qemu-utils ovmf qemu-efi-aarch64`
* Linux (Fedora/RHEL): `sudo dnf install qemu-system-x86 qemu-system-aarch64 qemu-img edk2-ovmf edk2-aarch64`
* macOS (Homebrew): `brew install qemu`
* Windows: download the installer from https://www.qemu.org/download/#windows and add the install directory to your PATH. Verify with `qemu-system-x86_64 --version` in a fresh terminal.

You also need OpenSSL (for the TLS exercise) and Wireshark on your host. Install via your package manager or https://www.wireshark.org/.

=== Step S2: download the two cloud images ===

We use Debian's ''generic cloud images'' because they are designed for virtualization and boot quickly. Both are ~600 MB.

* x86 server image: https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-amd64.qcow2
* ARM edge image: https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-arm64.qcow2

Save both to a working directory, e.g. `~/lab8/`.

=== Step S3: create a cloud-init seed image (one for each VM) ===

The cloud images expect a tiny "seed" disk on first boot that tells them the hostname, the user account, and an SSH key. Create two text files:

`user-data-server`:

<pre>
#cloud-config
hostname: lab8-server
users:
- name: lab
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
lock_passwd: false
plain_text_passwd: lab
ssh_authorized_keys:
- ssh-ed25519 AAAA... your-public-key-here
ssh_pwauth: true
chpasswd:
expire: false
</pre>

`user-data-edge` is identical except `hostname: lab8-edge`.

Also create a one-line `meta-data` file:

<pre>
instance-id: iid-local-01
</pre>

Build the seed images with `cloud-localds` (Linux, comes with `cloud-image-utils`) or with `genisoimage`/`mkisofs`:

<pre>
cloud-localds seed-server.iso user-data-server meta-data
cloud-localds seed-edge.iso user-data-edge meta-data
</pre>

If you do not have `cloud-localds`, the equivalent `genisoimage` invocation is:

<pre>
genisoimage -output seed-server.iso -volid cidata -joliet -rock \
user-data-server meta-data
</pre>

=== Step S4: resize the disk images ===

Default cloud images are tiny (~2 GB) and will fill up fast. Grow them to 8 GB each:

<pre>
qemu-img resize debian-12-genericcloud-amd64.qcow2 8G
qemu-img resize debian-12-genericcloud-arm64.qcow2 8G
</pre>

=== Step S5: boot the x86 server VM ===

Open a terminal and start the server:

<pre>
qemu-system-x86_64 \
-name lab8-server \
-machine q35 -accel kvm -accel whpx -accel hvf -accel tcg \
-cpu max -m 1024 -smp 2 \
-drive file=debian-12-genericcloud-amd64.qcow2,if=virtio \
-drive file=seed-server.iso,if=virtio,format=raw \
-netdev user,id=net0,hostfwd=tcp::2222-:22 \
-device virtio-net-pci,netdev=net0 \
-netdev socket,id=link,listen=:10000 \
-device virtio-net-pci,netdev=link,mac=52:54:00:12:34:56 \
-nographic
</pre>

Notes on this command line:

* The `-accel kvm -accel whpx -accel hvf -accel tcg` chain tells QEMU to try the fastest accelerator available on whatever host OS you are running, falling back to TCG. You only get one of them; QEMU picks whichever works.
* The first `-netdev user` is for outbound traffic (apt, etc.) and forwards host port 2222 to the guest's SSH.
* The second `-netdev socket,listen=:10000` is the inter-VM link --- this VM listens for the other VM to connect.
* `-nographic` disables the QEMU window and uses your terminal as the console. To exit QEMU: `Ctrl-A` then `X`.

First boot takes 30--90 seconds. Wait for the login prompt and log in with user `lab`, password `lab`.

In a second terminal, you can also SSH in:

<pre>
ssh -p 2222 lab@localhost
</pre>

=== Step S6: boot the ARM edge VM ===

In another terminal:

<pre>
qemu-system-aarch64 \
-name lab8-edge \
-machine virt -cpu max -m 1024 -smp 2 \
-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd \
-drive file=debian-12-genericcloud-arm64.qcow2,if=virtio \
-drive file=seed-edge.iso,if=virtio,format=raw \
-netdev user,id=net0,hostfwd=tcp::2223-:22 \
-device virtio-net-pci,netdev=net0 \
-netdev socket,id=link,connect=:10000 \
-device virtio-net-pci,netdev=link,mac=52:54:00:12:34:57 \
-nographic
</pre>

Notes:

* `-machine virt` is QEMU's generic ARM platform.
* `-bios` points to the UEFI firmware. The path varies by distro: on Fedora/RHEL it is `/usr/share/edk2/aarch64/QEMU_EFI.fd`; on macOS Homebrew it is `$(brew --prefix qemu)/share/qemu/edk2-aarch64-code.fd`; on Windows it ships in the QEMU install directory.
* The second `-netdev socket,connect=:10000` connects ''into'' the server VM's listening socket. Start the server first, then start the edge.
* SSH in via `ssh -p 2223 lab@localhost`.

ARM-on-x86 emulation is slow. Boot may take 5--10 minutes on first run. Be patient. On Apple Silicon hosts, ARM is native and boot is fast.

=== Step S7: configure the inter-VM link ===

The `socket` netdev gives each VM a second NIC, but the kernel does not auto-configure it. Inside ''each'' VM, find the second interface (probably `enp0s3` or `ens4`) and assign it a static IP on a private subnet:

On the server VM:

<pre>
sudo ip link set ens4 up
sudo ip addr add 172.30.0.1/24 dev ens4
</pre>

On the edge VM:

<pre>
sudo ip link set ens4 up
sudo ip addr add 172.30.0.2/24 dev ens4
</pre>

(Substitute the actual interface name. `ip a` shows it.)

Verify with `ping 172.30.0.2` from the server. If you see replies, the inter-VM link is up. If not, double-check that you started the server before the edge, and that both `socket` netdevs use the same port number.

=== Step S8: install lab dependencies on both VMs ===

Run on each VM:

<pre>
sudo apt update
sudo apt install -y build-essential cmake git \
libssl-dev nlohmann-json3-dev \
wireguard-tools tcpdump curl
</pre>

For cpp-httplib, just download the single header into your working directory:

<pre>
mkdir -p ~/lab8 && cd ~/lab8
wget https://raw.githubusercontent.com/yhirose/cpp-httplib/master/httplib.h
</pre>

You are now ready for the lab proper.

== Tasks ==

Work in your `~/lab8` directory. Keep all the small programs you write --- you will submit them.

# '''TCP echo, raw sockets.''' Write two C++ programs: a server that listens on TCP port 9000 and echoes back whatever it receives, and a client that connects, sends a short message read from `argv[1]`, prints the reply, and disconnects. Use POSIX sockets directly (`socket`, `bind`, `listen`, `accept`, `read`, `write`). Run the server on the server VM (binding to `172.30.0.1`); run the client from the edge VM, sending to `172.30.0.1:9000`. Verify the round trip works. Skim the data with `sudo tcpdump -i ens4 -A port 9000` on either VM during the exchange.

# '''HTTP/REST with cpp-httplib.''' Replace your TCP echo with an HTTP equivalent. The server exposes one POST endpoint, `/access`, which expects a JSON body of the form `{"card_id": "..."}` and replies with `{"granted": true}` if the card ID is in a hardcoded allow-list of your choice (at least three IDs), otherwise `{"granted": false}`. The client constructs the JSON, POSTs it, parses the reply, and prints `GRANTED` or `DENIED`. Use `nlohmann/json` for both encoding and decoding. Test from the command line first using `curl` against your server, before moving to the C++ client.

# '''Inspect the wire.''' Open Wireshark on the host, capturing on the loopback interface (since the QEMU socket link tunnels through host loopback). Trigger an HTTP request from your client. Find the request and the response in the capture. Confirm that you can read the card ID, the JSON body, and the headers in plaintext. Save a screenshot or the raw capture for your writeup.

# '''Add TLS.''' Generate a self-signed server certificate and matching key with `openssl`. Recompile your server program against the SSL-enabled cpp-httplib by defining `CPPHTTPLIB_OPENSSL_SUPPORT` and linking `-lssl -lcrypto`. Switch `httplib::Server` to `httplib::SSLServer`, passing your cert and key paths. Switch the client to `httplib::SSLClient` and configure it to trust your self-signed cert (or, for testing only, disable verification). Get the same `/access` endpoint working over HTTPS on port 9443. ''Note: search the cpp-httplib README for the exact constructor signatures --- they are stable but worth confirming against the version you downloaded.''

# '''Inspect the wire again.''' Capture the HTTPS exchange in Wireshark. Confirm that the JSON body and headers are no longer visible: you should see the TLS handshake (the `Client Hello`, `Server Hello`, `Certificate` messages should be readable as TLS metadata) followed by encrypted application data records. Note in your writeup what is still visible to an eavesdropper despite TLS (hint: at least the destination IP, port, and the SNI hostname in the handshake).

# '''Add a simple authentication step.''' Extend your HTTPS server to require an `Authorization: Bearer <token>` header. Reject any request without a valid token with HTTP 401. Choose any token value, and pass it from the client. Verify with `curl --cacert ./cert.pem -H "Authorization: Bearer ..."` that wrong tokens get 401 and the right one gets through.

# '''Generate the WireGuard keys.''' On each of the three peers --- your laptop (host), the server VM, the edge VM --- generate a private/public keypair with `wg genkey | tee privatekey | wg pubkey > publickey`. Collect all three public keys somewhere you can copy from. ''Treat the private keys as you would treat passwords.''

# '''Design the WireGuard topology.''' Pick virtual IPs for each peer on a private subnet (e.g. `10.66.0.1` for the host, `10.66.0.2` for the server VM, `10.66.0.3` for the edge VM). Decide which peer will act as the ''rendezvous'' --- the one with a stable, reachable address that the others connect ''to''. The host is the natural choice here because both VMs can reach it. Pick a UDP port for WireGuard (51820 is conventional).

# '''Write the three configs and bring them up.''' Create `/etc/wireguard/wg0.conf` on each peer with the appropriate `[Interface]` and one `[Peer]` block per other peer. The host's config has two `[Peer]` entries (one for each VM). Each VM's config has one `[Peer]` entry pointing at the host. Bring each interface up with `sudo wg-quick up wg0`, verify with `sudo wg show`. From inside the server VM, ping `10.66.0.3` (the edge); from the edge VM, ping `10.66.0.2` (the server). Both should succeed even though no direct socket netdev connects them.

# '''Re-run the HTTPS exercise over WireGuard.''' Stop your HTTPS server, restart it bound to the WireGuard IP `10.66.0.2` instead of `172.30.0.1`. Point the client at `https://10.66.0.2:9443/access`. Verify it still works. Capture the host's WireGuard UDP port in Wireshark this time --- you should see ''only'' encrypted UDP packets, with no visible TLS handshake or application protocol. Two layers of encryption, one capture: this is defense in depth.

# '''Short writeup.''' In a `WRITEUP.md` file at the root of your submission, answer:
## Which transport (raw TCP, HTTP, MQTT) would you use for the capstone, and why?
## What is still visible to an eavesdropper of HTTPS-without-VPN traffic?
## What is still visible to an eavesdropper of HTTPS-over-WireGuard traffic?
## Was the inter-VM connection for this lab actually NAT'd? Why or why not? (Look at your QEMU command lines and think carefully.)
## What would change if you replaced the QEMU edge VM with a real Raspberry Pi on your home network?

== Bonus tasks (optional) ==

Pick at most one. These earn no extra points but make a real difference to your project.

* '''MQTT pub/sub.''' Install `mosquitto` (broker) on the server VM and `mosquitto-clients` on the edge. Use `mosquitto_pub` and `mosquitto_sub` to send a "card scanned" event from the edge to the server over topic `lab8/door/cards`. Then write a tiny C++ subscriber using `paho-mqtt-cpp`. ''Hint:'' the broker speaks plaintext on port 1883 by default; for TLS use 8883.

* '''Mutual TLS.''' Extend your HTTPS exercise so the ''client'' also presents a certificate that the server verifies. This eliminates the need for the bearer token entirely, because possession of the private key proves identity.

* '''Replay protection.''' Add a nonce or timestamp to each `/access` request and have the server reject replays. Demonstrate that replaying a captured request with `curl` gets rejected.

* '''Persistent WireGuard.''' Configure `wg-quick` to start at boot on both VMs, so your tunnel survives a reboot.

== Deliverables ==

Submit a single archive (zip or tar) containing:

# Source code for all programs you wrote: TCP echo client/server, HTTP server/client, HTTPS variant, plus any bonus code.
# A `Makefile` or `CMakeLists.txt` that builds them. Pick whichever you prefer.
# All three WireGuard config files (with the private keys ''redacted''), one per peer, named clearly.
# Two Wireshark capture screenshots: one of plaintext HTTP showing the JSON, one of HTTPS-over-WireGuard showing only encrypted UDP.
# `WRITEUP.md` answering the questions in Task 11.

== Common pitfalls ==

''The ARM VM takes forever to boot.'' That is normal on x86 hosts without same-arch acceleration. Do not kill it; first boot is the slowest because cloud-init runs.

''The `socket` netdev does not connect the two VMs.'' Most common cause: starting the edge VM before the server VM, so there is nothing for the edge's `connect=:10000` to connect to. Start the server first.

''`ping 172.30.0.2` works but my TCP server is not reachable.'' Almost always a firewall on the server VM. Either disable the firewall (`sudo ufw disable` if active) or open the port.

''Wireshark shows no traffic on loopback.'' On Linux you may need to configure permissions: `sudo dpkg-reconfigure wireshark-common` and add yourself to the `wireshark` group, then log out and back in. On macOS, ChmodBPF must be installed (the Wireshark installer prompts for this).

''cpp-httplib does not compile.'' Make sure you are using a C++17-or-later compiler (`-std=c++17`). The header is large and the first compilation takes 10+ seconds.

''TLS verification fails on the client.'' Self-signed certificates are not trusted by default. You either pass the cert path explicitly (`set_ca_cert_path`) or, for testing only, disable verification (`enable_server_certificate_verification(false)`). The lab grading does not require a properly trusted cert.

''WireGuard handshake never completes.'' The most common cause is a typo in a public key. Public keys must match exactly between peers. Second most common: the ''rendezvous'' peer's UDP port is not actually reachable --- check host firewall settings and any `Endpoint` line that points at `localhost` vs an actual reachable IP.

''My VM lost the IP address on the inter-VM link after a reboot.'' Expected --- `ip addr add` is not persistent. Either re-run it after each boot, or write a `/etc/systemd/network/` config to make it permanent.

== Looking ahead ==

Next week we return to the CI pipeline with the third quality gate: ''dynamic analysis''. You will run Valgrind, AddressSanitizer, and UndefinedBehaviorSanitizer against the Oven Controller, find bugs that static analysis missed, and add a sanitizer build to your CI pipeline.

Software Development Process and Testing

2026-05-04T13:34:35Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]
* [[SDPT Lab 3]]
* [[SDPT Lab 4]]
* [[SDPT Lab 5]]
* [[SDPT Lab 6]]
* [[SDPT Lab 7]]
* [[SDPT Lab 8]]

SDPT Lab 7

2026-04-27T00:11:16Z

Rhobincu: /* Tasks */

= Week 7 Lab Activity: Adding a Static Analysis Quality Gate =

== Objective ==

Extend your Week 6 CI pipeline with a new <code>lint</code> stage that runs '''before''' the build and blocks Merge Requests on static analysis findings. By the end of this lab your pipeline gates code on three things: it must lint cleanly, it must compile, and it must pass tests.

== Background ==

In Week 6 you built a CI pipeline with at least <code>build</code> and <code>test</code> stages. Today you are adding a <code>lint</code> stage as the first stage. A failure there skips later stages and blocks the MR.

You will use two complementary tools. '''cppcheck''' is a fast, pattern-based analyzer that runs from the command line on your source tree without needing your build to succeed; its strength is speed and a low false-positive rate. '''clang-tidy''' is a deeper AST-based analyzer built on top of Clang, which means it understands templates, overloads, lifetimes, and modern C++ semantics. It ships hundreds of configurable checks grouped into families such as <code>bugprone-*</code>, <code>cert-*</code>, <code>cppcoreguidelines-*</code>, <code>modernize-*</code>, <code>performance-*</code>, and <code>readability-*</code>. The full catalog is at https://clang.llvm.org/extra/clang-tidy/checks/list.html.

clang-tidy needs to know exactly how each file is compiled (include paths, defines, C++ standard). CMake produces that information for free if you set <code>CMAKE_EXPORT_COMPILE_COMMANDS=ON</code>, which writes a <code>compile_commands.json</code> to your build directory. To make clang-tidy run automatically on every compile, set the CMake variable <code>CMAKE_CXX_CLANG_TIDY</code> to a clang-tidy command line --- CMake will then invoke clang-tidy alongside the compiler on every C++ source file. To run cppcheck from a build target, wrap it in an <code>add_custom_target</code> definition.

clang-tidy is configured by a <code>.clang-tidy</code> YAML file at the repo root. The two important keys for this lab are <code>Checks</code> (a comma-separated glob list, prefix <code>-</code> to disable) and <code>WarningsAsErrors</code> (same syntax). The conventional pattern is to start with <code>-*</code> and then re-enable only the families you want, rather than enabling everything and trying to silence the noise.

Both tools support inline suppressions: <code>// cppcheck-suppress <id></code> and <code>// NOLINTNEXTLINE(<check>)</code>. Always pair a suppression with a comment explaining ''why''. Unjustified suppressions are themselves a code smell.

For tool usage refer to <code>cppcheck --help</code>, <code>man cppcheck</code>, <code>clang-tidy --help</code>, and the check catalog linked above.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Extend the build environment.''' Update your <code>Dockerfile</code> so the image installs both <code>cppcheck</code> and <code>clang-tidy</code>. Rebuild the image and verify both binaries respond to <code>--version</code> from inside a container. If your runner pulls the image from a registry, push the new tag.
# '''Configure clang-tidy.''' Create <code>.clang-tidy</code> at the repository root. You must enable, at a minimum, the entire <code>bugprone-*</code> family and at least two specific checks from <code>cppcoreguidelines-*</code>. You must explicitly disable any check from those families that fires noisily on your existing code (e.g. some <code>readability-identifier-length</code> or <code>cppcoreguidelines-pro-bounds-*</code> checks are commonly muted in embedded code). Set <code>WarningsAsErrors</code> so any reported issue fails the build. Add a comment block at the top of the file explaining the rationale for your check selection --- this is part of the deliverable.
# '''Wire clang-tidy into CMake.''' Modify <code>CMakeLists.txt</code> so that compile commands are exported and clang-tidy runs automatically on every C++ compile. Make sure the build still works for team members who do not have clang-tidy installed locally (hint: <code>find_program</code> can return a NOTFOUND value, and you can branch on that).
# '''Add a cppcheck custom target.''' Define a CMake custom target named <code>cppcheck</code> that runs the tool on your source tree. Required flags: at minimum <code>--enable=warning,style,performance,portability</code>, <code>--error-exitcode=1</code> (so it propagates failures), <code>--inline-suppr</code> (so your inline suppressions are honored), and <code>--std=c++17</code> (or whatever your project uses). Decide for yourself whether to scan or skip the build directory, the test directory, and any third-party code.
# '''Add the lint stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>lint</code> stage as the first stage. Add a job that runs cppcheck inside your updated Docker image. The job must fail the pipeline on any cppcheck finding. clang-tidy itself does '''not''' need a separate CI job, since wiring it into <code>CMAKE_CXX_CLANG_TIDY</code> means it already runs during your existing build job.
# '''Clean up your existing code.''' Push your branch and let the pipeline run. If clang-tidy or cppcheck flags real issues in the Oven Controller, fix them properly. If you genuinely believe a finding is a false positive, suppress it inline with a justification comment --- but no more than two suppressions for this lab. Three or more suppressions almost always means you should fix the underlying problem instead.
# '''Verify the gate fires.''' Once the pipeline is fully green, introduce a deliberate bug on your branch. Pick something the tools should catch: a memory leak, a null pointer dereference, an uninitialized read, a forgotten <code>delete[]</code>, a use-after-move, a buffer overflow. Push the bug, confirm the <code>lint</code> or <code>build</code> stage fails, then preserve a copy of the relevant tool output (a job-log permalink in the MR description is sufficient). Revert the deliberate bug; your final pipeline must be green.
# '''Measure the cost.''' Compare the wall-clock time of your full pipeline before and after this lab. Record both numbers and the percentage increase in the MR description, along with one sentence on whether the trade-off is worth it for this codebase. Be honest --- "the lint stage adds 4 minutes and we caught zero real bugs today" is a valid finding.
# '''Review and merge.''' Open the MR and have a teammate review it. The reviewer should specifically check: the rationale comment in <code>.clang-tidy</code>, that any suppression has a justification, the visibility of the deliberate-bug pipeline run, and the cost measurement. Merge when approved.

== Stretch tasks (optional, if you finish early) ==

Pick at most one. These will not gain you points but will make your project measurably more professional.

* '''Tighten the rules.''' Add a check from <code>cert-*</code> or <code>clang-analyzer-*</code> and resolve all findings.
* '''Explore MISRA.''' cppcheck ships an experimental <code>misra</code> addon. Run it against your code (you may need a rules text file --- see the cppcheck addons documentation), and report the top three findings together with the MISRA rule numbers they correspond to.
* '''Add a pre-commit hook.''' Configure either a Git pre-commit hook or the <code>pre-commit</code> framework to run cppcheck on staged files. This catches issues before they reach CI and saves runner time.
* '''Generate a SARIF report.''' Configure clang-tidy to emit findings in SARIF format and upload it as a GitLab CI artifact. This is how findings are typically aggregated across larger projects.

== Deliverables ==

For this lab to be marked complete, your <code>main</code> branch must contain:

# A <code>Dockerfile</code> that installs both static analysis tools.
# A <code>.clang-tidy</code> file with a rationale comment and your chosen check set.
# A <code>CMakeLists.txt</code> that exports compile commands, hooks clang-tidy into the build, and defines a <code>cppcheck</code> custom target.
# A <code>.gitlab-ci.yml</code> with a <code>lint</code> stage running before the build stage.
# A merged MR whose linked Issue (or MR description) contains:
## The cost measurement from Task 8.
## A reference to the failed pipeline from Task 7 and the green pipeline that followed.
## A justification for any inline suppression added during Task 6.

== Common pitfalls ==

* '''clang-tidy reporting findings in third-party headers''' (Google Test, system headers, etc.). Constrain <code>HeaderFilterRegex</code> in <code>.clang-tidy</code> to match only your own paths.
* '''cppcheck warning about missing system headers.''' Add <code>--suppress=missingIncludeSystem</code> to your invocation.
* '''clang-tidy producing different findings on different machines.''' Almost always means <code>compile_commands.json</code> is missing or stale --- regenerate it after every CMake configure, and make sure the file is inside the build directory clang-tidy looks at.
* '''The pipeline timing out.''' clang-tidy is significantly slower than the compiler. If the full build now exceeds your runner's timeout, narrow your check set or scope <code>HeaderFilterRegex</code> more tightly.
* '''"It works on my machine but fails in CI."''' Almost always means your locally installed clang-tidy version differs from the one in the Docker image. The container is the source of truth.
* '''Suppressing checks instead of fixing code.''' If you find yourself adding a third suppression, stop and reconsider. The right action is almost always to fix the code, not to silence the tool.

== Looking ahead ==

Next week we leave the CI pipeline alone for one session and focus on the architecture of your capstone: how the Raspberry Pi and the VM server actually communicate. Bring your design questions about the project.

SDPT Lab 7

2026-04-27T00:10:17Z

Rhobincu:

= Week 7 Lab Activity: Adding a Static Analysis Quality Gate =

== Objective ==

Extend your Week 6 CI pipeline with a new <code>lint</code> stage that runs '''before''' the build and blocks Merge Requests on static analysis findings. By the end of this lab your pipeline gates code on three things: it must lint cleanly, it must compile, and it must pass tests.

== Background ==

In Week 6 you built a CI pipeline with at least <code>build</code> and <code>test</code> stages. Today you are adding a <code>lint</code> stage as the first stage. A failure there skips later stages and blocks the MR.

You will use two complementary tools. '''cppcheck''' is a fast, pattern-based analyzer that runs from the command line on your source tree without needing your build to succeed; its strength is speed and a low false-positive rate. '''clang-tidy''' is a deeper AST-based analyzer built on top of Clang, which means it understands templates, overloads, lifetimes, and modern C++ semantics. It ships hundreds of configurable checks grouped into families such as <code>bugprone-*</code>, <code>cert-*</code>, <code>cppcoreguidelines-*</code>, <code>modernize-*</code>, <code>performance-*</code>, and <code>readability-*</code>. The full catalog is at https://clang.llvm.org/extra/clang-tidy/checks/list.html.

clang-tidy needs to know exactly how each file is compiled (include paths, defines, C++ standard). CMake produces that information for free if you set <code>CMAKE_EXPORT_COMPILE_COMMANDS=ON</code>, which writes a <code>compile_commands.json</code> to your build directory. To make clang-tidy run automatically on every compile, set the CMake variable <code>CMAKE_CXX_CLANG_TIDY</code> to a clang-tidy command line --- CMake will then invoke clang-tidy alongside the compiler on every C++ source file. To run cppcheck from a build target, wrap it in an <code>add_custom_target</code> definition.

clang-tidy is configured by a <code>.clang-tidy</code> YAML file at the repo root. The two important keys for this lab are <code>Checks</code> (a comma-separated glob list, prefix <code>-</code> to disable) and <code>WarningsAsErrors</code> (same syntax). The conventional pattern is to start with <code>-*</code> and then re-enable only the families you want, rather than enabling everything and trying to silence the noise.

Both tools support inline suppressions: <code>// cppcheck-suppress <id></code> and <code>// NOLINTNEXTLINE(<check>)</code>. Always pair a suppression with a comment explaining ''why''. Unjustified suppressions are themselves a code smell.

For tool usage refer to <code>cppcheck --help</code>, <code>man cppcheck</code>, <code>clang-tidy --help</code>, and the check catalog linked above.

== Tasks ==

Work on a feature branch opened from a tracked Issue. Open a Merge Request when you are ready to integrate.

# '''Extend the build environment.''' Update your <code>Dockerfile</code> so the image installs both <code>cppcheck</code> and <code>clang-tidy</code>. Rebuild the image and verify both binaries respond to <code>--version</code> from inside a container. If your runner pulls the image from a registry, push the new tag.

# '''Configure clang-tidy.''' Create <code>.clang-tidy</code> at the repository root. You must enable, at a minimum, the entire <code>bugprone-*</code> family and at least two specific checks from <code>cppcoreguidelines-*</code>. You must explicitly disable any check from those families that fires noisily on your existing code (e.g. some <code>readability-identifier-length</code> or <code>cppcoreguidelines-pro-bounds-*</code> checks are commonly muted in embedded code). Set <code>WarningsAsErrors</code> so any reported issue fails the build. Add a comment block at the top of the file explaining the rationale for your check selection --- this is part of the deliverable.

# '''Wire clang-tidy into CMake.''' Modify <code>CMakeLists.txt</code> so that compile commands are exported and clang-tidy runs automatically on every C++ compile. Make sure the build still works for team members who do not have clang-tidy installed locally (hint: <code>find_program</code> can return a NOTFOUND value, and you can branch on that).

# '''Add a cppcheck custom target.''' Define a CMake custom target named <code>cppcheck</code> that runs the tool on your source tree. Required flags: at minimum <code>--enable=warning,style,performance,portability</code>, <code>--error-exitcode=1</code> (so it propagates failures), <code>--inline-suppr</code> (so your inline suppressions are honored), and <code>--std=c++17</code> (or whatever your project uses). Decide for yourself whether to scan or skip the build directory, the test directory, and any third-party code.

# '''Add the lint stage to GitLab CI.''' Edit <code>.gitlab-ci.yml</code> to add a new <code>lint</code> stage as the first stage. Add a job that runs cppcheck inside your updated Docker image. The job must fail the pipeline on any cppcheck finding. clang-tidy itself does '''not''' need a separate CI job, since wiring it into <code>CMAKE_CXX_CLANG_TIDY</code> means it already runs during your existing build job.

# '''Clean up your existing code.''' Push your branch and let the pipeline run. If clang-tidy or cppcheck flags real issues in the Oven Controller, fix them properly. If you genuinely believe a finding is a false positive, suppress it inline with a justification comment --- but no more than two suppressions for this lab. Three or more suppressions almost always means you should fix the underlying problem instead.

# '''Verify the gate fires.''' Once the pipeline is fully green, introduce a deliberate bug on your branch. Pick something the tools should catch: a memory leak, a null pointer dereference, an uninitialized read, a forgotten <code>delete[]</code>, a use-after-move, a buffer overflow. Push the bug, confirm the <code>lint</code> or <code>build</code> stage fails, then preserve a copy of the relevant tool output (a job-log permalink in the MR description is sufficient). Revert the deliberate bug; your final pipeline must be green.

# '''Measure the cost.''' Compare the wall-clock time of your full pipeline before and after this lab. Record both numbers and the percentage increase in the MR description, along with one sentence on whether the trade-off is worth it for this codebase. Be honest --- "the lint stage adds 4 minutes and we caught zero real bugs today" is a valid finding.

# '''Review and merge.''' Open the MR and have a teammate review it. The reviewer should specifically check: the rationale comment in <code>.clang-tidy</code>, that any suppression has a justification, the visibility of the deliberate-bug pipeline run, and the cost measurement. Merge when approved.

== Stretch tasks (optional, if you finish early) ==

Pick at most one. These will not gain you points but will make your project measurably more professional.

* '''Tighten the rules.''' Add a check from <code>cert-*</code> or <code>clang-analyzer-*</code> and resolve all findings.
* '''Explore MISRA.''' cppcheck ships an experimental <code>misra</code> addon. Run it against your code (you may need a rules text file --- see the cppcheck addons documentation), and report the top three findings together with the MISRA rule numbers they correspond to.
* '''Add a pre-commit hook.''' Configure either a Git pre-commit hook or the <code>pre-commit</code> framework to run cppcheck on staged files. This catches issues before they reach CI and saves runner time.
* '''Generate a SARIF report.''' Configure clang-tidy to emit findings in SARIF format and upload it as a GitLab CI artifact. This is how findings are typically aggregated across larger projects.

== Deliverables ==

For this lab to be marked complete, your <code>main</code> branch must contain:

# A <code>Dockerfile</code> that installs both static analysis tools.
# A <code>.clang-tidy</code> file with a rationale comment and your chosen check set.
# A <code>CMakeLists.txt</code> that exports compile commands, hooks clang-tidy into the build, and defines a <code>cppcheck</code> custom target.
# A <code>.gitlab-ci.yml</code> with a <code>lint</code> stage running before the build stage.
# A merged MR whose linked Issue (or MR description) contains:
## The cost measurement from Task 8.
## A reference to the failed pipeline from Task 7 and the green pipeline that followed.
## A justification for any inline suppression added during Task 6.

== Common pitfalls ==

* '''clang-tidy reporting findings in third-party headers''' (Google Test, system headers, etc.). Constrain <code>HeaderFilterRegex</code> in <code>.clang-tidy</code> to match only your own paths.
* '''cppcheck warning about missing system headers.''' Add <code>--suppress=missingIncludeSystem</code> to your invocation.
* '''clang-tidy producing different findings on different machines.''' Almost always means <code>compile_commands.json</code> is missing or stale --- regenerate it after every CMake configure, and make sure the file is inside the build directory clang-tidy looks at.
* '''The pipeline timing out.''' clang-tidy is significantly slower than the compiler. If the full build now exceeds your runner's timeout, narrow your check set or scope <code>HeaderFilterRegex</code> more tightly.
* '''"It works on my machine but fails in CI."''' Almost always means your locally installed clang-tidy version differs from the one in the Docker image. The container is the source of truth.
* '''Suppressing checks instead of fixing code.''' If you find yourself adding a third suppression, stop and reconsider. The right action is almost always to fix the code, not to silence the tool.

== Looking ahead ==

Next week we leave the CI pipeline alone for one session and focus on the architecture of your capstone: how the Raspberry Pi and the VM server actually communicate. Bring your design questions about the project.

SDPT Lab 7

2026-04-26T23:58:09Z

Rhobincu: Pagină nouă: = Week 7 Lab Activity: Adding a Static Analysis Quality Gate = == Introduction == In Week 6, you built a CI pipeline that automatically compiles and tests your Oven Controller co...

= Week 7 Lab Activity: Adding a Static Analysis Quality Gate =

== Introduction ==

In Week 6, you built a CI pipeline that automatically compiles and tests your Oven Controller code on every push. Today you will add a new stage that runs '''before''' the build: a <code>lint</code> stage that uses static analysis to catch entire classes of bugs that the compiler and the unit tests cannot.

By the end of this lab, you will have:

# Extended your Docker build environment to include <code>cppcheck</code> and <code>clang-tidy</code>.
# Created a <code>.clang-tidy</code> configuration file at the root of your project.
# Hooked clang-tidy into every CMake compile via <code>CMAKE_CXX_CLANG_TIDY</code>.
# Added a new <code>lint</code> stage to your <code>.gitlab-ci.yml</code> that runs cppcheck.
# Verified that introducing a deliberate bug causes the pipeline to fail and block a Merge Request.
# Fixed the deliberate bug and watched the pipeline turn green again.

== Prerequisites ==

You should be starting from your finished Week 6 project, which has:

* A working <code>CMakeLists.txt</code> for the Oven Controller.
* A passing Google Test suite.
* A <code>Dockerfile</code> producing a multi-arch build environment.
* A <code>.gitlab-ci.yml</code> with at least <code>build</code> and <code>test</code> stages running on a custom GitLab Runner.

If any of those is missing or broken, fix it before continuing. Static analysis added on top of a broken pipeline does not help anyone.

== Step 1: Create a Feature Branch ==

As always, do '''not''' work on <code>main</code>. Open an Issue first ("Add static analysis quality gate") and then create a feature branch:

<pre>
git checkout main
git pull
git checkout -b feature/static-analysis
</pre>

This branch will contain everything you do in this lab. At the end you will open a Merge Request just like in Week 2.

== Step 2: Update the Dockerfile ==

Open your <code>Dockerfile</code> and add <code>cppcheck</code> and <code>clang-tidy</code> to the <code>apt-get install</code> line.

<pre>
RUN apt-get update && apt-get install -y \
build-essential \
cmake \
g++-aarch64-linux-gnu \
qemu-user-static \
libgtest-dev \
cppcheck \
clang-tidy \
&& rm -rf /var/lib/apt/lists/*
</pre>

Rebuild the image locally to make sure it still works:

<pre>
docker build -t oven-build:lint-test .
docker run --rm oven-build:lint-test cppcheck --version
docker run --rm oven-build:lint-test clang-tidy --version
</pre>

You should see version strings for both tools. If either command is "not found," double-check the package names for your base image (Debian/Ubuntu use <code>cppcheck</code> and <code>clang-tidy</code>; on minimal images you may need <code>clang-tools</code> instead of <code>clang-tidy</code>).

== Step 3: Create the .clang-tidy Configuration File ==

In the root of your repository (next to <code>CMakeLists.txt</code>), create a new file named exactly <code>.clang-tidy</code> (note the leading dot). Paste the following:

<pre>
---
Checks: >
-*,
bugprone-*,
cert-*,
clang-analyzer-*,
cppcoreguidelines-pro-*,
cppcoreguidelines-slicing,
misc-unused-*,
modernize-use-nullptr,
modernize-use-override,
modernize-use-nodiscard,
performance-*,
portability-*,
readability-braces-around-statements,
readability-misleading-indentation,
readability-redundant-*,
-bugprone-easily-swappable-parameters,
-cppcoreguidelines-pro-bounds-pointer-arithmetic

WarningsAsErrors: '*'
HeaderFilterRegex: '.*'
FormatStyle: 'file'
</pre>

A few notes on what this configuration does:

* The first line <code>-*</code> '''disables''' every check, then we re-enable specific families. This is the safer approach because clang-tidy ships hundreds of checks and many are too noisy.
* <code>WarningsAsErrors: '*'</code> turns every remaining warning into an error. The pipeline will fail if any check fires.
* <code>HeaderFilterRegex: '.*'</code> tells clang-tidy to also analyze the project's headers (otherwise it skips them).
* The two trailing <code>-...</code> entries '''suppress''' specific checks that produce too many false positives in embedded code.

Commit this file:

<pre>
git add .clang-tidy
git commit -m "Add .clang-tidy configuration"
</pre>

== Step 4: Hook clang-tidy into CMake ==

Open <code>CMakeLists.txt</code> and add the following near the top, '''after''' the <code>project(...)</code> line but '''before''' any <code>add_executable</code> or <code>add_library</code> calls:

<pre>
# Generate compile_commands.json for tooling
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# Enable clang-tidy on every compile
find_program(CLANG_TIDY_EXE NAMES clang-tidy)
if(CLANG_TIDY_EXE)
set(CMAKE_CXX_CLANG_TIDY
${CLANG_TIDY_EXE}
--config-file=${CMAKE_SOURCE_DIR}/.clang-tidy)
message(STATUS "clang-tidy enabled: ${CLANG_TIDY_EXE}")
else()
message(WARNING "clang-tidy not found; lint disabled")
endif()
</pre>

The reason we wrap it in <code>if(CLANG_TIDY_EXE)</code> is so that team members who do not have clang-tidy installed locally can still build. The CI environment '''does''' have it, so the pipeline will still enforce it.

Test it locally:

<pre>
rm -rf build
docker run --rm -v $PWD:/work -w /work oven-build:lint-test \
bash -c "cmake -B build && cmake --build build"
</pre>

You should see <code>-- clang-tidy enabled: /usr/bin/clang-tidy</code> in the configure step, and during the build clang-tidy runs alongside the compiler. If your code is clean, the build still succeeds. If clang-tidy finds something, the build fails with a clang-tidy error message.

== Step 5: Add a Cppcheck Custom Target ==

cppcheck does not need CMake to drive it (it parses source directly), but adding a CMake target makes it convenient to run locally. Append this to <code>CMakeLists.txt</code>:

<pre>
# Cppcheck target (optional locally, mandatory in CI)
find_program(CPPCHECK_EXE NAMES cppcheck)
if(CPPCHECK_EXE)
add_custom_target(cppcheck
COMMAND ${CPPCHECK_EXE}
--enable=warning,style,performance,portability
--inline-suppr
--error-exitcode=1
--suppress=missingIncludeSystem
--std=c++17
-I ${CMAKE_SOURCE_DIR}/include
${CMAKE_SOURCE_DIR}/src
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
COMMENT "Running cppcheck on src/")
endif()
</pre>

Adjust the <code>-I</code> include path and the source path to match your project layout if it differs.

You can now run cppcheck locally with:

<pre>
cmake --build build --target cppcheck
</pre>

If your code is clean, the command prints nothing and exits with status 0.

Commit your CMake changes:

<pre>
git add CMakeLists.txt Dockerfile
git commit -m "Wire clang-tidy and cppcheck into the build"
</pre>

== Step 6: Add the lint Stage to GitLab CI ==

Open <code>.gitlab-ci.yml</code>. Add <code>lint</code> as the '''first''' stage in your <code>stages:</code> list:

<pre>
stages:
- lint
- build
- test
</pre>

Then add a new job that runs cppcheck. Place it above your existing <code>build</code> job:

<pre>
cppcheck:
stage: lint
image: $CI_REGISTRY_IMAGE/oven-build:latest
script:
- cppcheck
--enable=warning,style,performance,portability
--inline-suppr
--error-exitcode=1
--suppress=missingIncludeSystem
--std=c++17
-I include
src
</pre>

Note: clang-tidy is '''not''' a separate CI job. Because we wired it into <code>CMAKE_CXX_CLANG_TIDY</code>, it runs during the existing <code>build</code> job, on every translation unit. If clang-tidy reports an error, the build job fails just as if the compiler had failed. This is exactly the behavior we want: one pipeline run, multiple gates.

Commit and push your branch:

<pre>
git add .gitlab-ci.yml
git commit -m "Add lint stage running cppcheck"
git push -u origin feature/static-analysis
</pre>

Open a Merge Request from <code>feature/static-analysis</code> into <code>main</code>. The pipeline should run, the new <code>lint</code> stage should appear, and (assuming your code is clean) all stages should pass.

== Step 7: Trigger a Failure on Purpose ==

Quality gates are only useful if they actually catch things. Let us prove ours does.

Pick any <code>.cpp</code> file in your project --- for example <code>src/OvenController.cpp</code>. Add the following intentionally broken function near the top of the file, '''but inside the same namespace and class''' so it actually compiles:

<pre>
// Intentional bug for Week 7 lab. Remove before merge.
void OvenController::leakyDiagnostic() {
int* readings = new int[100];
if (sensors_.empty()) {
return; // <-- LEAK: never delete[] readings
}
for (int i = 0; i < 100; ++i) {
readings[i] = i;
}
delete[] readings;
}
</pre>

Also declare it in the corresponding header. Commit and push:

<pre>
git add src/OvenController.cpp include/OvenController.hpp
git commit -m "Add deliberate leak (lab demo, will revert)"
git push
</pre>

Now watch your Merge Request. The new pipeline run should:

# Start the <code>lint</code> stage.
# cppcheck reports the leak and exits non-zero.
# The <code>lint</code> job turns red.
# The <code>build</code> and <code>test</code> jobs are skipped (because <code>lint</code> failed).
# The Merge Request is automatically blocked from merging.

Click into the failed job and read the cppcheck output. You should see something close to:

<pre>
src/OvenController.cpp:42:5: error: Memory leak: readings [memleak]
</pre>

This is exactly what should happen. The pipeline did its job.

== Step 8: Fix and Merge ==

Revert the deliberate bug:

<pre>
git revert HEAD
git push
</pre>

(Or remove the function manually and commit. Either is fine.)

The new pipeline should pass all stages: <code>lint</code> green, <code>build</code> green (with clang-tidy clean), <code>test</code> green. Merge the MR via GitLab.

You now have a working, multi-stage CI pipeline that enforces both unit tests '''and''' static analysis on every change to the codebase.

== Deliverables ==

To be marked as complete, your <code>main</code> branch must contain:

# An updated <code>Dockerfile</code> with <code>cppcheck</code> and <code>clang-tidy</code> installed.
# A <code>.clang-tidy</code> configuration file at the repo root.
# A <code>CMakeLists.txt</code> that exports <code>compile_commands.json</code>, sets <code>CMAKE_CXX_CLANG_TIDY</code>, and defines a <code>cppcheck</code> custom target.
# A <code>.gitlab-ci.yml</code> with a <code>lint</code> stage running cppcheck '''before''' the <code>build</code> stage.
# A merged Merge Request whose pipeline shows '''four''' green jobs (lint, build, test, plus any others you already had).
# Evidence in the MR's pipeline history of '''at least one failed pipeline''' caused by the deliberate bug, followed by the fix.

== Common Issues ==

''clang-tidy reports many warnings on third-party headers (Google Test, system includes).''
* Make sure <code>HeaderFilterRegex</code> in <code>.clang-tidy</code> only matches your own headers, e.g. <code>'^src/|^include/'</code>.

''cppcheck complains about missing system headers.''
* That is what <code>--suppress=missingIncludeSystem</code> is for. Make sure you kept that flag.

''clang-tidy fails because it cannot find compile flags.''
* Confirm that <code>set(CMAKE_EXPORT_COMPILE_COMMANDS ON)</code> is in <code>CMakeLists.txt</code>, that <code>build/compile_commands.json</code> exists after configure, and that you ran CMake before clang-tidy.

''The pipeline runs forever, then times out.''
* clang-tidy is significantly slower than the compiler. If a full build now takes more than 10 minutes, consider narrowing your <code>Checks:</code> list. Start tight, loosen as you learn which checks pull their weight.

''My capstone project codebase already has dozens of warnings.''
* That is normal for an existing codebase. Two strategies: (1) fix them all in one MR, or (2) configure clang-tidy to warn-but-not-fail until you have cleaned things up. Option (1) is cleaner. Option (2) is realistic when you inherit legacy code.

== Looking Ahead ==

Next week we leave the CI pipeline alone and turn to the '''system architecture''' of your capstone: how does your Raspberry Pi actually talk to the VM server? Sockets, REST, MQTT, and the design trade-offs between them.

Software Development Process and Testing

2026-04-26T23:58:04Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]
* [[SDPT Lab 3]]
* [[SDPT Lab 4]]
* [[SDPT Lab 5]]
* [[SDPT Lab 6]]
* [[SDPT Lab 7]]

SDPT Lab 6

2026-04-20T17:49:47Z

Rhobincu:

= Week 6 Lab Activity: CI/CD Pipelines & Custom Runners =

== Objective ==
Today, we automate everything. You will transition from compiling code on your laptop to architecting a professional CI/CD pipeline.

We will accomplish this in six phases:
# '''Repository Setup:''' Migrating your code to GitLab.
# '''Infrastructure:''' Spinning up and registering your own local GitLab Runner via Docker.
# '''Continuous Integration (Build):''' Writing your first CI job and generating Artifacts.
# '''Continuous Integration (Test):''' Consuming Artifacts and testing via QEMU.
# '''Continuous Deployment (CD):''' Creating a simulated OTA firmware release restricted to the <code>main</code> branch.
# '''Cleanup:''' Deregistering and destroying your local runner.

----

== Phase 1: Repository Setup ==
'''1. Create a Project:'''
Log into GitLab and create a new blank project named <code>sdpt-smart-oven</code>. Uncheck "Initialize repository with a README".

'''2. Push Your Code:'''
Open your terminal on your laptop, navigate to your Week 5 project folder, and push your code to this new repository.
<syntaxhighlight lang="bash">
git init
git branch -m main
git remote add origin https://gitlab.cs.pub.ro/<your-username>/sdpt-smart-oven.git
git add .
git commit -m "Initial commit: Oven Controller with CMake and Docker"
git push -u origin main
</syntaxhighlight>

----

== Phase 2: Registering a Local Runner ==
GitLab provides shared runners, but embedded systems often require custom hardware or specific toolchains. We will host our own Runner!

'''1. Get Your Registration Token:'''
In your GitLab project, go to '''Settings''' -> '''CI/CD'''. Expand the '''Runners''' section. Under "Project runners", click "New project runner". Add the tag <code>local-embedded</code> and click Create. Copy the '''registration token''' it gives you.

'''2. Start the Runner via Docker:'''
On your laptop terminal, run a background Docker container to act as your runner. (We mount the Docker socket so the runner can spawn its own containers!)
<syntaxhighlight lang="bash">
docker run -d --name my-local-runner --restart always -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
</syntaxhighlight>

'''3. Register the Runner:'''
Now, execute the registration command inside the running container:
<syntaxhighlight lang="bash">
docker exec -it my-local-runner gitlab-runner register
</syntaxhighlight>
* '''GitLab instance URL:''' <code>https://gitlab.cs.pub.ro/</code>
* '''Registration token:''' (Paste your token from step 1)
* '''Description:''' My Laptop Runner
* '''Tags:''' <code>local-embedded</code>
* '''Executor:''' <code>docker</code>
* '''Default image:''' <code>ubuntu:22.04</code>

Refresh your GitLab Runners page. You should see a green circle indicating your local runner is alive and listening for jobs!

----

== Phase 3: The Build Stage & Artifacts ==
We will now tell your Runner how to build our code. Create a file named exactly <code>.gitlab-ci.yml</code> in your project root.

'''Your Challenge (Part 1):'''
# '''Image:''' Set <code>image:</code> to the ARM Docker image you built last week.
# '''Stages:''' Define three stages: <code>build</code>, <code>test</code>, and <code>deploy</code>.
# '''The Build Job:''' Create a job named <code>compile_firmware</code>.
#* Assign it to the <code>build</code> stage.
#* Use <code>tags: [local-embedded]</code> to force this job to run on YOUR laptop's runner.
#* In the <code>script</code>, run CMake for <code>aarch64</code> and run <code>make</code>.
#* Create <code>artifacts</code> to save the <code>build/</code> directory (expire in 1 hour).

Commit and push. Watch the pipeline in GitLab. Your laptop's fan might spin up because *your* Docker daemon is doing the heavy lifting!

----

== Phase 4: The Test Stage & Merge Checks ==
'''Your Challenge (Part 2):'''
Add a job named <code>verify_logic</code>:
# Stage: <code>test</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Require the artifacts from <code>compile_firmware</code>.
# <code>script:</code> Navigate to <code>build/</code> and execute tests using QEMU (<code>qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests</code>).

'''Test the Block:'''
# Go to GitLab '''Settings''' -> '''Merge Requests''' -> Check "Pipelines must succeed".
# Create a new branch: <code>git checkout -b feature/broken-math</code>
# Break an assertion in your C++ tests and push the branch.
# Open a Merge Request. Watch the test stage fail and observe the Merge button physically lock you out! Fix the code, push again, and Merge it.

----

== Phase 5: Continuous Deployment (CD) ==
Once the code hits the <code>main</code> branch, we want to handle two different types of deployments: an automated OTA release (Pull), and an on-demand Edge deployment (Push).

'''Your Challenge (Part 3): Automated OTA Release'''
Add a job named <code>release_ota_firmware</code>:
# Stage: <code>deploy</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Pull from <code>compile_firmware</code>.
# <code>script:</code> Rename your binary to a release format and simulate cryptographically signing it:
#* <code>mv build/unit_tests build/firmware_v1.bin</code>
#* <code>echo "CRYPTOGRAPHIC_SIGNATURE_OK" >> build/firmware_v1.bin</code>
# '''Rules:''' We ONLY want to release firmware automatically from the main branch! Add a <code>rules:</code> section with <code>- if: '$CI_COMMIT_BRANCH == "main"'</code>.
# '''Artifacts:''' Save <code>build/firmware_v1.bin</code> as an artifact that never expires.

'''Your Challenge (Part 4): On-Demand Push Deployment'''
Sometimes we need to instantly push an update to a specific machine (e.g., a prototype in the lab) without waiting for it to poll. We will simulate an SSH deployment using pipeline variables.

Add another job named <code>deploy_to_edge_device</code>:
# Stage: <code>deploy</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Pull from <code>compile_firmware</code>.
# '''Rules:''' We want this to be an "On-Demand" job that requires a human to click a play button. Add a <code>rules:</code> section with <code>- when: manual</code>.
# <code>script:</code> Simulate securely pushing the binary to a specific IP address using an environment variable (<code>$TARGET_IP</code>). Do not hardcode an IP here; we will inject it later!
#* <code>echo "Connecting to Edge Device at $TARGET_IP..."</code>
#* <code>echo "scp build/unit_tests admin@$TARGET_IP:/opt/smart-oven/bin/"</code>
#* <code>echo "Deployment to $TARGET_IP successful!"</code>

'''Test the Deployments:'''
# Push your code to <code>main</code>.
# You will see the <code>release_ota_firmware</code> job run automatically.
# The <code>deploy_to_edge_device</code> job will be paused (marked with a "Play" icon).
# Click the Play icon. GitLab will take you to a new screen asking if you want to inject any environment variables.
# Add a variable with the Key <code>TARGET_IP</code> and the Value <code>192.168.1.50</code> (or any dummy IP address you prefer).
# Click "Run job" and check the terminal output to see your variable successfully injected into the simulated SSH command!

== Phase 6: Cleanup ==
To prevent your runner from polling GitLab forever and draining your laptop battery, gracefully shut it down and remove it:
<syntaxhighlight lang="bash">
docker stop my-local-runner
docker rm my-local-runner
</syntaxhighlight>
In the GitLab UI, go back to Settings -> CI/CD -> Runners, and delete the offline runner.

----
=== Assignment Submission ===
Upload '''ONLY''' your finalized <code>.gitlab-ci.yml</code> to the Moodle VPL assignment. The automated grading server will analyze your YAML syntax to ensure you correctly configured the stages, artifacts, custom runner routing, and deployment rules.

SDPT Lab 6

2026-04-19T17:27:43Z

Rhobincu: /* Phase 5: Continuous Deployment (CD) */

= Week 6 Lab Activity: CI/CD Pipelines & Custom Runners =

== Objective ==
Today, we automate everything. You will transition from compiling code on your laptop to architecting a professional CI/CD pipeline.

We will accomplish this in six phases:
# '''Repository Setup:''' Migrating your code to GitLab.
# '''Infrastructure:''' Spinning up and registering your own local GitLab Runner via Docker.
# '''Continuous Integration (Build):''' Writing your first CI job and generating Artifacts.
# '''Continuous Integration (Test):''' Consuming Artifacts and testing via QEMU.
# '''Continuous Deployment (CD):''' Creating a simulated OTA firmware release restricted to the <code>main</code> branch.
# '''Cleanup:''' Deregistering and destroying your local runner.

----

== Phase 1: Repository Setup ==
'''1. Create a Project:'''
Log into GitLab and create a new blank project named <code>sdpt-smart-oven</code>. Uncheck "Initialize repository with a README".

'''2. Push Your Code:'''
Open your terminal on your laptop, navigate to your Week 5 project folder, and push your code to this new repository.
<syntaxhighlight lang="bash">
git init
git branch -m main
git remote add origin https://gitlab.com/<your-username>/sdpt-smart-oven.git
git add .
git commit -m "Initial commit: Oven Controller with CMake and Docker"
git push -u origin main
</syntaxhighlight>

----

== Phase 2: Registering a Local Runner ==
GitLab provides shared runners, but embedded systems often require custom hardware or specific toolchains. We will host our own Runner!

'''1. Get Your Registration Token:'''
In your GitLab project, go to '''Settings''' -> '''CI/CD'''. Expand the '''Runners''' section. Under "Project runners", click "New project runner". Add the tag <code>local-embedded</code> and click Create. Copy the '''registration token''' it gives you.

'''2. Start the Runner via Docker:'''
On your laptop terminal, run a background Docker container to act as your runner. (We mount the Docker socket so the runner can spawn its own containers!)
<syntaxhighlight lang="bash">
docker run -d --name my-local-runner --restart always -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
</syntaxhighlight>

'''3. Register the Runner:'''
Now, execute the registration command inside the running container:
<syntaxhighlight lang="bash">
docker exec -it my-local-runner gitlab-runner register
</syntaxhighlight>
* '''GitLab instance URL:''' <code>https://gitlab.com/</code>
* '''Registration token:''' (Paste your token from step 1)
* '''Description:''' My Laptop Runner
* '''Tags:''' <code>local-embedded</code>
* '''Executor:''' <code>docker</code>
* '''Default image:''' <code>ubuntu:22.04</code>

Refresh your GitLab Runners page. You should see a green circle indicating your local runner is alive and listening for jobs!

----

== Phase 3: The Build Stage & Artifacts ==
We will now tell your Runner how to build our code. Create a file named exactly <code>.gitlab-ci.yml</code> in your project root.

'''Your Challenge (Part 1):'''
# '''Image:''' Set <code>image:</code> to the ARM Docker image you built last week.
# '''Stages:''' Define three stages: <code>build</code>, <code>test</code>, and <code>deploy</code>.
# '''The Build Job:''' Create a job named <code>compile_firmware</code>.
#* Assign it to the <code>build</code> stage.
#* Use <code>tags: [local-embedded]</code> to force this job to run on YOUR laptop's runner.
#* In the <code>script</code>, run CMake for <code>aarch64</code> and run <code>make</code>.
#* Create <code>artifacts</code> to save the <code>build/</code> directory (expire in 1 hour).

Commit and push. Watch the pipeline in GitLab. Your laptop's fan might spin up because *your* Docker daemon is doing the heavy lifting!

----

== Phase 4: The Test Stage & Merge Checks ==
'''Your Challenge (Part 2):'''
Add a job named <code>verify_logic</code>:
# Stage: <code>test</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Require the artifacts from <code>compile_firmware</code>.
# <code>script:</code> Navigate to <code>build/</code> and execute tests using QEMU (<code>qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests</code>).

'''Test the Block:'''
# Go to GitLab '''Settings''' -> '''Merge Requests''' -> Check "Pipelines must succeed".
# Create a new branch: <code>git checkout -b feature/broken-math</code>
# Break an assertion in your C++ tests and push the branch.
# Open a Merge Request. Watch the test stage fail and observe the Merge button physically lock you out! Fix the code, push again, and Merge it.

----

== Phase 5: Continuous Deployment (CD) ==
Once the code hits the <code>main</code> branch, we want to handle two different types of deployments: an automated OTA release (Pull), and an on-demand Edge deployment (Push).

'''Your Challenge (Part 3): Automated OTA Release'''
Add a job named <code>release_ota_firmware</code>:
# Stage: <code>deploy</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Pull from <code>compile_firmware</code>.
# <code>script:</code> Rename your binary to a release format and simulate cryptographically signing it:
#* <code>mv build/unit_tests build/firmware_v1.bin</code>
#* <code>echo "CRYPTOGRAPHIC_SIGNATURE_OK" >> build/firmware_v1.bin</code>
# '''Rules:''' We ONLY want to release firmware automatically from the main branch! Add a <code>rules:</code> section with <code>- if: '$CI_COMMIT_BRANCH == "main"'</code>.
# '''Artifacts:''' Save <code>build/firmware_v1.bin</code> as an artifact that never expires.

'''Your Challenge (Part 4): On-Demand Push Deployment'''
Sometimes we need to instantly push an update to a specific machine (e.g., a prototype in the lab) without waiting for it to poll. We will simulate an SSH deployment using pipeline variables.

Add another job named <code>deploy_to_edge_device</code>:
# Stage: <code>deploy</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Pull from <code>compile_firmware</code>.
# '''Rules:''' We want this to be an "On-Demand" job that requires a human to click a play button. Add a <code>rules:</code> section with <code>- when: manual</code>.
# <code>script:</code> Simulate securely pushing the binary to a specific IP address using an environment variable (<code>$TARGET_IP</code>). Do not hardcode an IP here; we will inject it later!
#* <code>echo "Connecting to Edge Device at $TARGET_IP..."</code>
#* <code>echo "scp build/unit_tests admin@$TARGET_IP:/opt/smart-oven/bin/"</code>
#* <code>echo "Deployment to $TARGET_IP successful!"</code>

'''Test the Deployments:'''
# Push your code to <code>main</code>.
# You will see the <code>release_ota_firmware</code> job run automatically.
# The <code>deploy_to_edge_device</code> job will be paused (marked with a "Play" icon).
# Click the Play icon. GitLab will take you to a new screen asking if you want to inject any environment variables.
# Add a variable with the Key <code>TARGET_IP</code> and the Value <code>192.168.1.50</code> (or any dummy IP address you prefer).
# Click "Run job" and check the terminal output to see your variable successfully injected into the simulated SSH command!

== Phase 6: Cleanup ==
To prevent your runner from polling GitLab forever and draining your laptop battery, gracefully shut it down and remove it:
<syntaxhighlight lang="bash">
docker stop my-local-runner
docker rm my-local-runner
</syntaxhighlight>
In the GitLab UI, go back to Settings -> CI/CD -> Runners, and delete the offline runner.

----
=== Assignment Submission ===
Upload '''ONLY''' your finalized <code>.gitlab-ci.yml</code> to the Moodle VPL assignment. The automated grading server will analyze your YAML syntax to ensure you correctly configured the stages, artifacts, custom runner routing, and deployment rules.

SDPT Lab 6

2026-04-19T17:08:20Z

Rhobincu: /* Phase 5: Continuous Deployment (CD) */

= Week 6 Lab Activity: CI/CD Pipelines & Custom Runners =

== Objective ==
Today, we automate everything. You will transition from compiling code on your laptop to architecting a professional CI/CD pipeline.

We will accomplish this in six phases:
# '''Repository Setup:''' Migrating your code to GitLab.
# '''Infrastructure:''' Spinning up and registering your own local GitLab Runner via Docker.
# '''Continuous Integration (Build):''' Writing your first CI job and generating Artifacts.
# '''Continuous Integration (Test):''' Consuming Artifacts and testing via QEMU.
# '''Continuous Deployment (CD):''' Creating a simulated OTA firmware release restricted to the <code>main</code> branch.
# '''Cleanup:''' Deregistering and destroying your local runner.

----

== Phase 1: Repository Setup ==
'''1. Create a Project:'''
Log into GitLab and create a new blank project named <code>sdpt-smart-oven</code>. Uncheck "Initialize repository with a README".

'''2. Push Your Code:'''
Open your terminal on your laptop, navigate to your Week 5 project folder, and push your code to this new repository.
<syntaxhighlight lang="bash">
git init
git branch -m main
git remote add origin https://gitlab.com/<your-username>/sdpt-smart-oven.git
git add .
git commit -m "Initial commit: Oven Controller with CMake and Docker"
git push -u origin main
</syntaxhighlight>

----

== Phase 2: Registering a Local Runner ==
GitLab provides shared runners, but embedded systems often require custom hardware or specific toolchains. We will host our own Runner!

'''1. Get Your Registration Token:'''
In your GitLab project, go to '''Settings''' -> '''CI/CD'''. Expand the '''Runners''' section. Under "Project runners", click "New project runner". Add the tag <code>local-embedded</code> and click Create. Copy the '''registration token''' it gives you.

'''2. Start the Runner via Docker:'''
On your laptop terminal, run a background Docker container to act as your runner. (We mount the Docker socket so the runner can spawn its own containers!)
<syntaxhighlight lang="bash">
docker run -d --name my-local-runner --restart always -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
</syntaxhighlight>

'''3. Register the Runner:'''
Now, execute the registration command inside the running container:
<syntaxhighlight lang="bash">
docker exec -it my-local-runner gitlab-runner register
</syntaxhighlight>
* '''GitLab instance URL:''' <code>https://gitlab.com/</code>
* '''Registration token:''' (Paste your token from step 1)
* '''Description:''' My Laptop Runner
* '''Tags:''' <code>local-embedded</code>
* '''Executor:''' <code>docker</code>
* '''Default image:''' <code>ubuntu:22.04</code>

Refresh your GitLab Runners page. You should see a green circle indicating your local runner is alive and listening for jobs!

----

== Phase 3: The Build Stage & Artifacts ==
We will now tell your Runner how to build our code. Create a file named exactly <code>.gitlab-ci.yml</code> in your project root.

'''Your Challenge (Part 1):'''
# '''Image:''' Set <code>image:</code> to the ARM Docker image you built last week.
# '''Stages:''' Define three stages: <code>build</code>, <code>test</code>, and <code>deploy</code>.
# '''The Build Job:''' Create a job named <code>compile_firmware</code>.
#* Assign it to the <code>build</code> stage.
#* Use <code>tags: [local-embedded]</code> to force this job to run on YOUR laptop's runner.
#* In the <code>script</code>, run CMake for <code>aarch64</code> and run <code>make</code>.
#* Create <code>artifacts</code> to save the <code>build/</code> directory (expire in 1 hour).

Commit and push. Watch the pipeline in GitLab. Your laptop's fan might spin up because *your* Docker daemon is doing the heavy lifting!

----

== Phase 4: The Test Stage & Merge Checks ==
'''Your Challenge (Part 2):'''
Add a job named <code>verify_logic</code>:
# Stage: <code>test</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Require the artifacts from <code>compile_firmware</code>.
# <code>script:</code> Navigate to <code>build/</code> and execute tests using QEMU (<code>qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests</code>).

'''Test the Block:'''
# Go to GitLab '''Settings''' -> '''Merge Requests''' -> Check "Pipelines must succeed".
# Create a new branch: <code>git checkout -b feature/broken-math</code>
# Break an assertion in your C++ tests and push the branch.
# Open a Merge Request. Watch the test stage fail and observe the Merge button physically lock you out! Fix the code, push again, and Merge it.

----

== Phase 5: Continuous Deployment (CD) ==
Once the code hits the <code>main</code> branch, we want to handle two different types of deployments: an automated OTA release (Pull), and an on-demand Edge deployment (Push).

'''Your Challenge (Part 3): Automated OTA Release'''
Add a job named <code>release_ota_firmware</code>:
# Stage: <code>deploy</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Pull from <code>compile_firmware</code>.
# <code>script:</code> Rename your binary to a release format and simulate cryptographically signing it:
#* <code>mv build/unit_tests build/firmware_v1.bin</code>
#* <code>echo "CRYPTOGRAPHIC_SIGNATURE_OK" >> build/firmware_v1.bin</code>
# '''Rules:''' We ONLY want to release firmware automatically from the main branch! Add a <code>rules:</code> section with <code>- if: '$CI_COMMIT_BRANCH == "main"'</code>.
# '''Artifacts:''' Save <code>build/firmware_v1.bin</code> as an artifact that never expires.

'''Your Challenge (Part 4): On-Demand Push Deployment'''
Sometimes we need to instantly push an update to a specific machine (e.g., a prototype in the lab) without waiting for it to poll. We will simulate an SSH deployment using pipeline variables.

Add another job named <code>deploy_to_edge_device</code>:
# Stage: <code>deploy</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Pull from <code>compile_firmware</code>.
# '''Rules:''' We want this to be an "On-Demand" job that requires a human to click a play button. Add a <code>rules:</code> section with <code>- when: manual</code>.
# <code>script:</code> Simulate securely pushing the binary to a specific IP address using an environment variable (<code>$TARGET_IP</code>):
#* <code>echo "Connecting to Edge Device at $TARGET_IP..."</code>
#* <code>echo "scp build/unit_tests admin@$TARGET_IP:/opt/smart-oven/bin/"</code>
#* <code>echo "Deployment to $TARGET_IP successful!"</code>

'''Test the Deployments:'''
# Push your code to <code>main</code>.
# You will see the <code>release_ota_firmware</code> job run automatically.
# The <code>deploy_to_edge_device</code> job will be paused (marked with a "Play" icon).
# Click the Play icon, and GitLab will allow you to manually input a value for <code>TARGET_IP</code> before executing the push!

== Phase 6: Cleanup ==
To prevent your runner from polling GitLab forever and draining your laptop battery, gracefully shut it down and remove it:
<syntaxhighlight lang="bash">
docker stop my-local-runner
docker rm my-local-runner
</syntaxhighlight>
In the GitLab UI, go back to Settings -> CI/CD -> Runners, and delete the offline runner.

----
=== Assignment Submission ===
Upload '''ONLY''' your finalized <code>.gitlab-ci.yml</code> to the Moodle VPL assignment. The automated grading server will analyze your YAML syntax to ensure you correctly configured the stages, artifacts, custom runner routing, and deployment rules.

SDPT Lab 6

2026-04-19T17:05:52Z

Rhobincu:

= Week 6 Lab Activity: CI/CD Pipelines & Custom Runners =

== Objective ==
Today, we automate everything. You will transition from compiling code on your laptop to architecting a professional CI/CD pipeline.

We will accomplish this in six phases:
# '''Repository Setup:''' Migrating your code to GitLab.
# '''Infrastructure:''' Spinning up and registering your own local GitLab Runner via Docker.
# '''Continuous Integration (Build):''' Writing your first CI job and generating Artifacts.
# '''Continuous Integration (Test):''' Consuming Artifacts and testing via QEMU.
# '''Continuous Deployment (CD):''' Creating a simulated OTA firmware release restricted to the <code>main</code> branch.
# '''Cleanup:''' Deregistering and destroying your local runner.

----

== Phase 1: Repository Setup ==
'''1. Create a Project:'''
Log into GitLab and create a new blank project named <code>sdpt-smart-oven</code>. Uncheck "Initialize repository with a README".

'''2. Push Your Code:'''
Open your terminal on your laptop, navigate to your Week 5 project folder, and push your code to this new repository.
<syntaxhighlight lang="bash">
git init
git branch -m main
git remote add origin https://gitlab.com/<your-username>/sdpt-smart-oven.git
git add .
git commit -m "Initial commit: Oven Controller with CMake and Docker"
git push -u origin main
</syntaxhighlight>

----

== Phase 2: Registering a Local Runner ==
GitLab provides shared runners, but embedded systems often require custom hardware or specific toolchains. We will host our own Runner!

'''1. Get Your Registration Token:'''
In your GitLab project, go to '''Settings''' -> '''CI/CD'''. Expand the '''Runners''' section. Under "Project runners", click "New project runner". Add the tag <code>local-embedded</code> and click Create. Copy the '''registration token''' it gives you.

'''2. Start the Runner via Docker:'''
On your laptop terminal, run a background Docker container to act as your runner. (We mount the Docker socket so the runner can spawn its own containers!)
<syntaxhighlight lang="bash">
docker run -d --name my-local-runner --restart always -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
</syntaxhighlight>

'''3. Register the Runner:'''
Now, execute the registration command inside the running container:
<syntaxhighlight lang="bash">
docker exec -it my-local-runner gitlab-runner register
</syntaxhighlight>
* '''GitLab instance URL:''' <code>https://gitlab.com/</code>
* '''Registration token:''' (Paste your token from step 1)
* '''Description:''' My Laptop Runner
* '''Tags:''' <code>local-embedded</code>
* '''Executor:''' <code>docker</code>
* '''Default image:''' <code>ubuntu:22.04</code>

Refresh your GitLab Runners page. You should see a green circle indicating your local runner is alive and listening for jobs!

----

== Phase 3: The Build Stage & Artifacts ==
We will now tell your Runner how to build our code. Create a file named exactly <code>.gitlab-ci.yml</code> in your project root.

'''Your Challenge (Part 1):'''
# '''Image:''' Set <code>image:</code> to the ARM Docker image you built last week.
# '''Stages:''' Define three stages: <code>build</code>, <code>test</code>, and <code>deploy</code>.
# '''The Build Job:''' Create a job named <code>compile_firmware</code>.
#* Assign it to the <code>build</code> stage.
#* Use <code>tags: [local-embedded]</code> to force this job to run on YOUR laptop's runner.
#* In the <code>script</code>, run CMake for <code>aarch64</code> and run <code>make</code>.
#* Create <code>artifacts</code> to save the <code>build/</code> directory (expire in 1 hour).

Commit and push. Watch the pipeline in GitLab. Your laptop's fan might spin up because *your* Docker daemon is doing the heavy lifting!

----

== Phase 4: The Test Stage & Merge Checks ==
'''Your Challenge (Part 2):'''
Add a job named <code>verify_logic</code>:
# Stage: <code>test</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Require the artifacts from <code>compile_firmware</code>.
# <code>script:</code> Navigate to <code>build/</code> and execute tests using QEMU (<code>qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests</code>).

'''Test the Block:'''
# Go to GitLab '''Settings''' -> '''Merge Requests''' -> Check "Pipelines must succeed".
# Create a new branch: <code>git checkout -b feature/broken-math</code>
# Break an assertion in your C++ tests and push the branch.
# Open a Merge Request. Watch the test stage fail and observe the Merge button physically lock you out! Fix the code, push again, and Merge it.

----

== Phase 5: Continuous Deployment (CD) ==
Once the code hits the <code>main</code> branch, we want to automatically package it for an Over-The-Air (OTA) firmware update.

'''Your Challenge (Part 3):'''
Add a final job named <code>release_ota_firmware</code>:
# Stage: <code>deploy</code>
# Tags: <code>local-embedded</code>
# <code>dependencies:</code> Pull from <code>compile_firmware</code>.
# <code>script:</code> Rename your binary to a release format and simulate cryptographically signing it:
#* <code>mv build/unit_tests build/firmware_v1.bin</code>
#* <code>echo "CRYPTOGRAPHIC_SIGNATURE_OK" >> build/firmware_v1.bin</code>
# '''Rules:''' We ONLY want to release firmware from the main branch! Add a <code>rules:</code> section with <code>- if: '$CI_COMMIT_BRANCH == "main"'</code>.
# '''Artifacts:''' Save <code>build/firmware_v1.bin</code> as an artifact that never expires.

Push to main. You should see a 3-stage pipeline complete successfully. You can now download your final "signed" firmware directly from the GitLab UI!

----

== Phase 6: Cleanup ==
To prevent your runner from polling GitLab forever and draining your laptop battery, gracefully shut it down and remove it:
<syntaxhighlight lang="bash">
docker stop my-local-runner
docker rm my-local-runner
</syntaxhighlight>
In the GitLab UI, go back to Settings -> CI/CD -> Runners, and delete the offline runner.

----
=== Assignment Submission ===
Upload '''ONLY''' your finalized <code>.gitlab-ci.yml</code> to the Moodle VPL assignment. The automated grading server will analyze your YAML syntax to ensure you correctly configured the stages, artifacts, custom runner routing, and deployment rules.

SDPT Lab 6

2026-04-19T17:03:02Z

Rhobincu: Pagină nouă: = Week 6 Lab Activity: Continuous Integration (CI) with GitLab = == Objective == Today, we automate everything. You will transition from compiling code on your laptop to architect...

= Week 6 Lab Activity: Continuous Integration (CI) with GitLab =

== Objective ==
Today, we automate everything. You will transition from compiling code on your laptop to architecting a professional CI pipeline. You will use your Docker image from last week to cross-compile your C++ code, run your Google Tests in QEMU, and configure GitLab to mechanically prevent broken code from ever reaching the <code>main</code> branch.

We will accomplish this in four phases:
# '''Repository Setup:''' Migrating your code to GitLab.
# '''The Build Stage:''' Writing your first CI job and generating Artifacts.
# '''The Test Stage:''' Consuming Artifacts and failing the pipeline on bad tests.
# '''Merge Checks:''' Enforcing quality control via Merge Requests.

----

== Phase 1: Repository Setup ==
To use GitLab CI, your code must live on a GitLab server.

'''1. Create a Project:'''
Log into GitLab and create a new blank project named <code>sdpt-smart-oven</code>. Uncheck "Initialize repository with a README".

'''2. Push Your Code:'''
Open your terminal on your laptop, navigate to your Week 5 project folder, and push your code to this new repository.
<syntaxhighlight lang="bash">
git init
git branch -m main
git remote add origin https://gitlab.com/<your-username>/sdpt-smart-oven.git
git add .
git commit -m "Initial commit: Oven Controller with CMake and Docker"
git push -u origin main
</syntaxhighlight>

----

== Phase 2: The Build Stage & Artifacts ==
We will now tell the GitLab Runner how to build our code using the Docker image you designed last week.

'''Your Challenge:'''
Create a file named exactly <code>.gitlab-ci.yml</code> in the root of your project. Write the YAML to meet these specifications:

# '''Image:''' Set the global <code>image:</code> to the Docker registry URL of the ARM image you built in Week 5 (or use a public equivalent provided by the instructor, e.g., <code>registry.gitlab.com/sdpt-course/arm-build-env:latest</code>).
# '''Stages:''' Define two stages: <code>build</code> and <code>test</code>.
# '''The Build Job:''' Create a job named <code>compile_firmware</code>.
#* Assign it to the <code>build</code> stage.
#* In the <code>script</code> section, create a build folder, run CMake for the <code>aarch64</code> compiler, and run <code>make</code>.
# '''Artifacts:''' Tell GitLab to save the <code>build/</code> directory as an artifact that expires in 1 hour. (If you forget this, your compiled binary will be deleted before the test stage starts!)

Commit and push this file. Go to your GitLab project -> '''Build''' -> '''Pipelines'''. You should see your pipeline running! Click on it to watch the live terminal output of the GitLab Runner.

----

== Phase 3: The Test Stage ==
Once your build job turns green, it's time to test the artifact.

'''Update your YAML:'''
Add a second job named <code>verify_logic</code> to your <code>.gitlab-ci.yml</code>:
# Assign it to the <code>test</code> stage.
# Use the <code>dependencies:</code> keyword to explicitly require the artifacts from <code>compile_firmware</code>.
# In the <code>script</code> section, navigate to the <code>build/</code> directory and execute your tests using QEMU (<code>qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests</code>).

Push the updated YAML. Watch the pipeline. The Runner will download the compiled binary from the previous stage and execute your tests!

----

== Phase 4: Merge Checks and Failure (The DevOps Climax) ==
A pipeline is useless if developers can just bypass it. We will now configure GitLab to block bad code.

'''1. Protect the Main Branch:'''
In GitLab, go to '''Settings''' -> '''Merge Requests'''.
Scroll down to '''Merge checks''' and check the box that says: ''"Pipelines must succeed"''. Save changes.

'''2. Create a Feature Branch:'''
Back on your laptop terminal, create a new branch:
<syntaxhighlight lang="bash">
git checkout -b feature/broken-sensor
</syntaxhighlight>

'''3. Sabotage the Code!'''
Open your <code>test_oven.cpp</code> file. Intentionally change a mathematical assertion so that it will fail (e.g., change <code>EXPECT_EQ(temp, 100);</code> to <code>EXPECT_EQ(temp, 999);</code>).

'''4. Push and Open a Merge Request:'''
Commit your broken test and push the branch to GitLab.
<syntaxhighlight lang="bash">
git commit -am "feat: updated sensor logic (with bugs)"
git push -u origin feature/broken-sensor
</syntaxhighlight>
In GitLab, open a '''Merge Request''' from your feature branch into <code>main</code>.

'''5. Observe the Block:'''
Wait for the pipeline to run. The Build stage will pass, but the Test stage will turn RED because Google Test caught your broken math.
Look at the Merge Request page. '''The Merge button is physically disabled!''' GitLab has successfully protected your production code from human error.

'''6. Fix and Merge:'''
Fix the test on your laptop, commit, and push again. The pipeline will automatically re-run, turn green, and unlock the Merge button. Click Merge!

----
=== Assignment Submission ===
Upload '''ONLY''' your finalized <code>.gitlab-ci.yml</code> to the Moodle VPL assignment. The automated grading server will analyze your YAML syntax to ensure you correctly configured the stages, artifacts, and QEMU execution.

Software Development Process and Testing

2026-04-19T17:02:55Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]
* [[SDPT Lab 3]]
* [[SDPT Lab 4]]
* [[SDPT Lab 5]]
* [[SDPT Lab 6]]

SDPT Lab 5

2026-03-30T13:55:46Z

Rhobincu:

= Week 5 Lab Activity: Containerization & Cross-Compilation =

== Objective ==
This week, we eliminate the "It works on my machine" problem. You will learn how to build isolated Linux environments, cross-compile your <code>OvenController</code> C++ code for an ARM architecture, and solve the complex problem of linking third-party static and dynamic libraries compiled for foreign architectures.

We will accomplish this in three phases:
# '''Preparing CMake:''' Updating the build system to link an external database library.
# '''The Manual Container (The "Old Way"):''' Building the cross-compilation environment by hand to understand the underlying mechanics.
# '''Infrastructure as Code (The "Modern Way"):''' Automating the entire environment with a <code>Dockerfile</code>.

----

== Phase 1: Preparing CMake for Foreign Libraries ==
Imagine our <code>OvenController</code> needs to log telemetry data locally using an SQLite database. To do this, we need to link the <code>sqlite3</code> library.

Open your <code>CMakeLists.txt</code> from Week 4 and add the standard linking commands. ''(Note: CMake is smart enough to look for the correct architecture version of this library based on the compiler we provide later).''

<syntaxhighlight lang="cmake">
# Add this near the bottom of your CMakeLists.txt
find_package(PkgConfig REQUIRED)
pkg_check_modules(SQLITE3 REQUIRED sqlite3)

# Add the includes and link the library to your executable
target_include_directories(unit_tests PRIVATE ${SQLITE3_INCLUDE_DIRS})
target_link_libraries(unit_tests PRIVATE ${SQLITE3_LIBRARIES})
</syntaxhighlight>

----

== Phase 2: The Manual Container (The "Old Way") ==
Before we automate, let's understand what Docker is actually doing under the hood.

'''1. Start a raw, interactive Ubuntu container:'''
Open your terminal and run a fresh Ubuntu 22.04 image, mounting your current code directory into <code>/app</code>:
<syntaxhighlight lang="bash">
docker run -it --name manual-build-env -v ${PWD}:/app ubuntu:22.04 /bin/bash
</syntaxhighlight>
''Notice your terminal prompt has changed. You are now the root user inside an isolated Linux environment.''

'''2. The "Multiarch" Superpower:'''
If we just run <code>apt-get install libsqlite3-dev</code>, Ubuntu will download the <code>x86_64</code> version. If we try to cross-compile our ARM code against it, the linker will violently crash. We must explicitly tell Ubuntu's package manager to accept packages for a foreign architecture (<code>arm64</code>).
<syntaxhighlight lang="bash">
dpkg --add-architecture arm64
apt-get update
</syntaxhighlight>

'''3. Install the Toolchain and Foreign Libraries:'''
Now we install our cross-compiler, QEMU emulator, and the specifically compiled '''ARM version''' of our library (<code>:arm64</code>).
<syntaxhighlight lang="bash">
apt-get install -y build-essential cmake pkg-config g++-aarch64-linux-gnu qemu-user qemu-user-static
apt-get install -y libsqlite3-dev:arm64
</syntaxhighlight>

'''4. Cross-Compile and Emulate:'''
Navigate to your mounted code and build the project for ARM. We use a command-line flag to tell CMake to use the ARM compiler instead of native GCC.
<syntaxhighlight lang="bash">
cd /app
mkdir build_arm && cd build_arm
cmake -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ ..
make
</syntaxhighlight>

If you try to run <code>./unit_tests</code> natively, Linux will throw an <code>Exec format error</code>. Use QEMU to emulate the execution of your ARM binary. Because we linked a dynamic library, we must tell QEMU where to find the ARM shared objects (<code>-L</code> flag):
<syntaxhighlight lang="bash">
qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests
</syntaxhighlight>
''Verify that your Google Tests pass on the emulated architecture!'' Type <code>exit</code> to leave and stop the container.

----

== Phase 3: Infrastructure as Code (The "Modern Way") ==
Manually typing <code>apt-get</code> commands, enabling architectures, and committing containers is tedious and error-prone. Modern DevOps engineers automate this using a <code>Dockerfile</code>.

'''Your Challenge:'''
Create a file named exactly <code>Dockerfile</code> (no extension) in your project root. Translate the manual steps you just took into an automated recipe that meets the following strict specifications:

# '''Base Image:''' Must use <code>ubuntu:22.04</code>.
# '''Environment:''' Set <code>DEBIAN_FRONTEND</code> to <code>noninteractive</code> to prevent the build from hanging on timezone prompts.
# '''Architecture:''' Use a <code>RUN</code> command to add the <code>arm64</code> architecture to <code>dpkg</code>.
# '''The Mega-Layer:''' Use a single <code>RUN</code> command to update <code>apt-get</code>, install all required tools (<code>build-essential cmake pkg-config g++-aarch64-linux-gnu qemu-user qemu-user-static libsqlite3-dev:arm64</code>), and immediately clean up the apt cache (<code>rm -rf /var/lib/apt/lists/*</code>) to keep the image size small. ''(Hint: Chain your commands with <code>&&</code> and use <code>\</code> for multi-line formatting).''
# '''Workspace:''' Set the working directory inside the container to <code>/app</code>.
# '''PID 1:''' Set the default command (<code>CMD</code>) to launch <code>/bin/bash</code> so the container stays alive interactively.

'''Build and Test Your Image:'''
Once you have written your Dockerfile, test your infrastructure code by building and running it. It should behave exactly like your manual container did:
<syntaxhighlight lang="bash">
docker build -t automated-arm-env:latest .
docker run -it --rm -v ${PWD}:/app automated-arm-env:latest
</syntaxhighlight>

----
=== Assignment Submission ===
Upload '''ONLY''' your <code>Dockerfile</code> to the Moodle VPL assignment. The automated grading server will run static analysis on your infrastructure-as-code syntax to verify your architecture setup, toolchain requirements, and layer optimization.

SDPT Lab 5

2026-03-30T13:52:27Z

Rhobincu:

= Week 5 Lab Activity: Containerization & Cross-Compilation =

== Objective ==
This week, we eliminate the "It works on my machine" problem. You will learn how to build isolated Linux environments, cross-compile your <code>OvenController</code> C++ code for an ARM architecture, and solve the complex problem of linking third-party static and dynamic libraries compiled for foreign architectures.

We will accomplish this in three phases:
# '''Preparing CMake:''' Updating the build system to link an external database library.
# '''The Manual Container (The "Old Way"):''' Building the cross-compilation environment by hand to understand the underlying mechanics.
# '''Infrastructure as Code (The "Modern Way"):''' Automating the entire environment with a <code>Dockerfile</code>.

----

== Phase 1: Preparing CMake for Foreign Libraries ==
Imagine our <code>OvenController</code> needs to log telemetry data locally using an SQLite database. To do this, we need to link the <code>sqlite3</code> library.

Open your <code>CMakeLists.txt</code> from Week 4 and add the standard linking commands. ''(Note: CMake is smart enough to look for the correct architecture version of this library based on the compiler we provide later).''

<syntaxhighlight lang="cmake">
# Add this near the bottom of your CMakeLists.txt
find_package(PkgConfig REQUIRED)
pkg_check_modules(SQLITE3 REQUIRED sqlite3)

# Add the includes and link the library to your executable
target_include_directories(unit_tests PRIVATE ${SQLITE3_INCLUDE_DIRS})
target_link_libraries(unit_tests PRIVATE ${SQLITE3_LIBRARIES})
</syntaxhighlight>

----

== Phase 2: The Manual Container (The "Old Way") ==
Before we automate, let's understand what Docker is actually doing under the hood.

'''1. Start a raw, interactive Ubuntu container:'''
Open your terminal and run a fresh Ubuntu 22.04 image, mounting your current code directory into <code>/app</code>:
<syntaxhighlight lang="bash">
docker run -it --name manual-build-env -v ${PWD}:/app ubuntu:22.04 /bin/bash
</syntaxhighlight>
''Notice your terminal prompt has changed. You are now the root user inside an isolated Linux environment.''

'''2. The "Multiarch" Superpower:'''
If we just run <code>apt-get install libsqlite3-dev</code>, Ubuntu will download the <code>x86_64</code> version. If we try to cross-compile our ARM code against it, the linker will violently crash. We must explicitly tell Ubuntu's package manager to accept packages for a foreign architecture (<code>arm64</code>).
<syntaxhighlight lang="bash">
dpkg --add-architecture arm64
apt-get update
</syntaxhighlight>

'''3. Install the Toolchain and Foreign Libraries:'''
Now we install our cross-compiler, QEMU emulator, and the specifically compiled '''ARM version''' of our library (<code>:arm64</code>).
<syntaxhighlight lang="bash">
apt-get install -y build-essential cmake pkg-config g++-aarch64-linux-gnu qemu-user qemu-user-static
apt-get install -y libsqlite3-dev:arm64
</syntaxhighlight>

'''4. Cross-Compile and Emulate:'''
Navigate to your mounted code and build the project for ARM. We use a command-line flag to tell CMake to use the ARM compiler instead of native GCC.
<syntaxhighlight lang="bash">
cd /app
mkdir build_arm && cd build_arm
cmake -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ ..
make
</syntaxhighlight>

If you try to run <code>./unit_tests</code> natively, Linux will throw an <code>Exec format error</code>. Use QEMU to emulate the execution of your ARM binary. Because we linked a dynamic library, we must tell QEMU where to find the ARM shared objects (<code>-L</code> flag):
<syntaxhighlight lang="bash">
qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests
</syntaxhighlight>
''Verify that your Google Tests pass on the emulated architecture!'' Type <code>exit</code> to leave and stop the container.

----

== Phase 3: Infrastructure as Code (The "Modern Way") ==
Manually typing <code>apt-get</code> commands, enabling architectures, and committing containers is tedious and error-prone. Modern DevOps engineers automate this using a <code>Dockerfile</code>.

'''1. Write the Dockerfile:'''
Create a file named exactly <code>Dockerfile</code> (no extension) in your project root. Translate the manual steps you just took into an automated recipe.

<syntaxhighlight lang="dockerfile">
# 1. Base Image
FROM ubuntu:22.04

# 2. Prevent interactive timezone prompts
ENV DEBIAN_FRONTEND=noninteractive

# 3. Enable ARM64 Architecture for foreign libraries
RUN dpkg --add-architecture arm64

# 4. Install toolchain & ARM libraries in ONE layer to save space
RUN apt-get update && apt-get install -y \
build-essential \
cmake \
pkg-config \
g++-aarch64-linux-gnu \
qemu-user \
qemu-user-static \
libsqlite3-dev:arm64 \
&& rm -rf /var/lib/apt/lists/*

# 5. Set Workspace
WORKDIR /app

# 6. Keep the container alive interactively
CMD ["/bin/bash"]
</syntaxhighlight>

'''2. Build the Automated Image:'''
Ask Docker Engine to read your recipe and build the image from scratch.
<syntaxhighlight lang="bash">
docker build -t automated-arm-env:latest .
</syntaxhighlight>

'''3. Run your Final Environment:'''
<syntaxhighlight lang="bash">
docker run -it --rm -v ${PWD}:/app automated-arm-env:latest
</syntaxhighlight>
You now have a perfectly reproducible, portable embedded toolchain that natively resolves third-party ARM dependencies.

----
=== Assignment Submission ===
Upload '''ONLY''' your <code>Dockerfile</code> to the Moodle VPL assignment. The automated grading server will run static analysis on your infrastructure-as-code syntax to verify your architecture setup, toolchain requirements, and layer optimization.

SDPT Lab 5

2026-03-30T13:49:46Z

Rhobincu: Pagină nouă: # Week 5 Lab Activity: Containerization & Cross-Compilation ## Objective This week, we eliminate the "It works on my machine" problem. You will learn how to build isolated Linux e...

# Week 5 Lab Activity: Containerization & Cross-Compilation

## Objective
This week, we eliminate the "It works on my machine" problem. You will learn how to build isolated Linux environments, cross-compile your `OvenController` C++ code for an ARM architecture, and solve the complex problem of linking third-party static and dynamic libraries compiled for foreign architectures.

We will accomplish this in three phases:
1. **Preparing CMake:** Updating the build system to link an external database library.
2. **The Manual Container (The "Old Way"):** Building the cross-compilation environment by hand to understand the underlying mechanics.
3. **Infrastructure as Code (The "Modern Way"):** Automating the entire environment with a `Dockerfile`.

## Phase 1: Preparing CMake for Foreign Libraries
Imagine our `OvenController` needs to log telemetry data locally using an SQLite database. To do this, we need to link the `sqlite3` library.

Open your `CMakeLists.txt` from Week 4 and add the standard linking commands. *(Note: CMake is smart enough to look for the correct architecture version of this library based on the compiler we provide later).*

```cmake
# Add this near the bottom of your CMakeLists.txt
find_package(PkgConfig REQUIRED)
pkg_check_modules(SQLITE3 REQUIRED sqlite3)

# Add the includes and link the library to your executable
target_include_directories(unit_tests PRIVATE ${SQLITE3_INCLUDE_DIRS})
target_link_libraries(unit_tests PRIVATE ${SQLITE3_LIBRARIES})
```

## Phase 2: The Manual Container (The "Old Way")
Before we automate, let's understand what Docker is actually doing under the hood.

**1. Start a raw, interactive Ubuntu container:**
Open your terminal and run a fresh Ubuntu 22.04 image, mounting your current code directory into `/app`:
```bash
docker run -it --name manual-build-env -v ${PWD}:/app ubuntu:22.04 /bin/bash
```
*Notice your terminal prompt has changed. You are now the `root` user inside an isolated Linux environment.*

**2. The "Multiarch" Superpower:**
If we just run `apt-get install libsqlite3-dev`, Ubuntu will download the `x86_64` version. If we try to cross-compile our ARM code against it, the linker will violently crash. We must explicitly tell Ubuntu's package manager to accept packages for a foreign architecture (`arm64`).
```bash
dpkg --add-architecture arm64
apt-get update
```

**3. Install the Toolchain and Foreign Libraries:**
Now we install our cross-compiler, QEMU emulator, and the specifically compiled **ARM version** of our library (`:arm64`).
```bash
apt-get install -y build-essential cmake pkg-config g++-aarch64-linux-gnu qemu-user qemu-user-static
apt-get install -y libsqlite3-dev:arm64
```

**4. Cross-Compile and Emulate:**
Navigate to your mounted code and build the project for ARM. We use a command-line flag to tell CMake to use the ARM compiler instead of native GCC.
```bash
cd /app
mkdir build_arm && cd build_arm
cmake -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ ..
make
```

If you try to run `./unit_tests` natively, Linux will throw an `Exec format error`. Use QEMU to emulate the execution of your ARM binary. Because we linked a dynamic library, we must tell QEMU where to find the ARM shared objects (`-L` flag):
```bash
qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./unit_tests
```
*Verify that your Google Tests pass on the emulated architecture!* Type `exit` to leave and stop the container.

## Phase 3: Infrastructure as Code (The "Modern Way")
Manually typing `apt-get` commands, enabling architectures, and committing containers is tedious and error-prone. Modern DevOps engineers automate this using a `Dockerfile`.

**1. Write the Dockerfile:**
Create a file named exactly `Dockerfile` (no extension) in your project root. Translate the manual steps you just took into an automated recipe.

```dockerfile
# 1. Base Image
FROM ubuntu:22.04

# 2. Prevent interactive timezone prompts
ENV DEBIAN_FRONTEND=noninteractive

# 3. Enable ARM64 Architecture for foreign libraries
RUN dpkg --add-architecture arm64

# 4. Install toolchain & ARM libraries in ONE layer to save space
RUN apt-get update && apt-get install -y \
build-essential \
cmake \
pkg-config \
g++-aarch64-linux-gnu \
qemu-user \
qemu-user-static \
libsqlite3-dev:arm64 \
&& rm -rf /var/lib/apt/lists/*

# 5. Set Workspace
WORKDIR /app

# 6. Keep the container alive interactively
CMD ["/bin/bash"]
```

**2. Build the Automated Image:**
Ask Docker Engine to read your recipe and build the image from scratch.
```bash
docker build -t automated-arm-env:latest .
```

**3. Run your Final Environment:**
```bash
docker run -it --rm -v ${PWD}:/app automated-arm-env:latest
```
You now have a perfectly reproducible, portable embedded toolchain that natively resolves third-party ARM dependencies.

### Assignment Submission
Upload **ONLY** your `Dockerfile` to the Moodle VPL assignment. The automated grading server will run static analysis on your infrastructure-as-code syntax to verify your architecture setup, toolchain requirements, and layer optimization.

Software Development Process and Testing

2026-03-30T13:47:36Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]
* [[SDPT Lab 3]]
* [[SDPT Lab 4]]
* [[SDPT Lab 5]]

SDPT Lab 4

2026-03-23T13:32:44Z

Rhobincu:

= Lab 4: Software Verification - TDD, Mocking, and Code Coverage =

== Introduction ==
In traditional embedded systems, testing involves compiling code, flashing it to a board, and physically observing the hardware. This is slow, expensive, and scales poorly. Today, we implement "Shift-Left Testing." We will verify our C++ logic on our Host PC using automated frameworks before it ever touches a microcontroller.

=== Goals ===
* Integrate Google Test and Google Mock via CMake.
* Write Unit Tests using the AAA (Arrange, Act, Assert) pattern.
* Use Dependency Injection to decouple business logic from hardware registers.
* Simulate hardware interactions using Google Mock (GMock).
* Generate interactive HTML Code Coverage reports using <code>gcovr</code>.

== Part 1: Theoretical Reference ==
''Use this section as a reference manual to complete the challenges in Part 2.''

=== 1.1 Google Test & Mock Cheat Sheet ===
'''Basic Assertions:'''
* <code>EXPECT_EQ(actual, expected);</code> (Non-fatal equality check)
* <code>EXPECT_FLOAT_EQ(actual, expected);</code> (Safe float comparison)
* <code>EXPECT_TRUE(condition);</code>

'''Mocking an Interface (GMock):'''
<pre>
class MockSensor : public ISensor {
public:
// MOCK_METHOD(ReturnType, MethodName, (Arguments), (override));
MOCK_METHOD(float, read_temperature, (), (override));
};
</pre>

'''Setting Mock Expectations:'''
<pre>
MockSensor fake_sensor;
// Program the mock to return 45.0 exactly twice.
EXPECT_CALL(fake_sensor, read_temperature())
.Times(2)
.WillRepeatedly(testing::Return(45.0f));
</pre>

=== 1.2 CMake Debug & Coverage Setup ===
Coverage mathematically requires a completely unoptimized binary mapping exactly to your source code lines.
<pre>
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
target_compile_options(my_target PRIVATE -O0 -g --coverage)
target_link_options(my_target PRIVATE --coverage)
endif()
</pre>

=== 1.3 Running gcovr ===
Execute this from inside your <code>build/</code> directory after running the tests:
<pre>
gcovr -r ../ . --html --html-details -o coverage.html -e ".*_deps.*"
</pre>

=== 1.4 Official Documentation & Tutorials ===
When you get stuck on syntax or advanced features during the lab, refer to these official resources:
* '''Google Test:''' [https://google.github.io/googletest/primer.html Googletest Primer (Official Tutorial)]
* '''Google Mock:''' [https://google.github.io/googletest/gmock_for_dummies.html gMock for Dummies] and the [https://google.github.io/googletest/reference/mocking.html Mocking Reference]
* '''CMake FetchContent:''' [https://cmake.org/cmake/help/latest/module/FetchContent.html Official CMake FetchContent Documentation]
* '''Code Coverage (gcovr):''' [https://gcovr.com/en/stable/guide.html gcovr User Guide]

== Part 2: The Challenges ==

=== Setup: The Raw Materials ===
You are building the safety controller for an industrial oven. It must read temperatures from an I2C sensor and trigger a physical alarm if it overheats.

Create a new workspace (<code>sdpt-lab4</code>). Create <code>include/</code> and <code>src/</code> directories. Populate them with these three files:

'''<code>include/ISensor.h</code>''' (The Hardware Interface)
<pre>
#pragma once

// Pure virtual interface. We DO NOT implement hardware logic here.
class ISensor {
public:
virtual float read_temperature() = 0;
virtual ~ISensor() = default;
};
</pre>

'''<code>include/OvenController.h</code>''' (The Logic Module)
<pre>
#pragma once
#include "ISensor.h"

class OvenController {
private:
ISensor* temp_sensor;
bool alarm_active;
float max_safe_temp;

public:
// Constructor uses Dependency Injection!
OvenController(ISensor* sensor, float safe_limit = 250.0f);

void check_safety();
bool is_alarm_active() const;

// Pure math function
static float raw_adc_to_celsius(int adc_value);
};
</pre>

'''<code>src/OvenController.cpp</code>''' (The Buggy Implementation)
<pre>
#include "../include/OvenController.h"

OvenController::OvenController(ISensor* sensor, float safe_limit)
: temp_sensor(sensor), alarm_active(false), max_safe_temp(safe_limit) {}

void OvenController::check_safety() {
float current_temp = temp_sensor->read_temperature();

// BUG 1: It only triggers if STRICTLY greater. What if it equals the limit?
if (current_temp > max_safe_temp) {
alarm_active = true;
} else {
alarm_active = false;
}
}

bool OvenController::is_alarm_active() const {
return alarm_active;
}

float OvenController::raw_adc_to_celsius(int adc_value) {
// BUG 2: Integer division truncates the decimal! (e.g., 5/2 = 2, not 2.5)
return (adc_value / 4095) * 330.0f;
}
</pre>

=== Challenge 1: The Verification Build System (Estimated: 20 mins) ===
We need a build system that fetches Google Test and compiles our code with coverage instrumentation.
'''Your Task:'''
# Create a <code>CMakeLists.txt</code> in the root directory.
# Build a static library named <code>oven_lib</code> containing <code>src/OvenController.cpp</code>.
# Use <code>FetchContent</code> to pull Google Test (<code>https://github.com/google/googletest.git</code>, tag <code>v1.13.0</code>).
# Create an executable named <code>unit_tests</code>. (You will create <code>tests/test_oven.cpp</code> in the next step).
# Link <code>oven_lib</code>, <code>gtest_main</code>, and <code>gmock</code> to your test executable.
# Add the CMake logic to inject <code>-O0 -g --coverage</code> ONLY if the build type is "Debug".

'''Verification:''' Run <code>cmake -DCMAKE_BUILD_TYPE=Debug ..</code> inside your build folder. It must configure without errors and download GTest.

=== Challenge 2: Pure Math TDD (Estimated: 25 mins) ===
Let's catch the integer division bug using the Red-Green-Refactor cycle.
'''Your Task:'''
# Create a <code>tests/</code> directory and a <code>tests/test_oven.cpp</code> file.
# Include <code><gtest/gtest.h></code> and your <code>OvenController.h</code>.
# Write a <code>TEST(MathTest, ConvertsADCToCelsius)</code>.
# Use <code>EXPECT_FLOAT_EQ</code> to assert that an ADC value of <code>2047</code> (roughly half of 4095) returns approximately <code>164.957f</code>.
# Compile and run <code>./unit_tests</code>. (Watch it fail! This is the RED phase).
# Refactor <code>OvenController.cpp</code> to fix the integer division bug. Recompile. (Watch it pass! This is the GREEN phase).

=== Challenge 3: Hardware Mocking (Estimated: 40 mins) ===
We need to test <code>check_safety()</code>, but we are on a PC. We have no I2C hardware. We must mock the <code>ISensor</code>.
'''Your Task:'''
# In your test file, include <code><gmock/gmock.h></code>.
# Create a <code>MockSensor</code> class that inherits from <code>ISensor</code>. Use <code>MOCK_METHOD</code> to mock <code>read_temperature</code>.
# Write a <code>TEST(SafetyTest, TriggersAlarmOnOverheat)</code>.
#* '''Arrange:''' Instantiate the MockSensor. Instantiate the OvenController, injecting the mock sensor into it with a safe limit of 250.0f.
#* '''Expectation:''' Program the mock to return <code>260.0f</code> when called.
#* '''Act:''' Call <code>check_safety()</code>.
#* '''Assert:''' Expect that <code>is_alarm_active()</code> is true.
# Write a second test: <code>TEST(SafetyTest, TriggersAlarmExactlyAtLimit)</code>.
#* Program the mock to return exactly <code>250.0f</code>.
#* Run the test. It will FAIL due to Bug 1. Fix the production code so it triggers on `>=`.

=== Challenge 4: The Coverage Report (Estimated: 15 mins) ===
Did we test every branch of our code? Let's prove it mathematically.
'''Your Task:'''
# Ensure you have run <code>./unit_tests</code> at least once so the <code>.gcda</code> files are generated.
# Run the <code>gcovr</code> command provided in the Theoretical Reference section.
# Open the resulting <code>coverage.html</code> file in your web browser. Check that you have achieved 100% branch coverage.

== Submission and Evaluation (Moodle VPL) ==
For this lab, your work will be automatically graded by the Moodle Virtual Programming Lab (VPL) engine.

'''How to submit:'''
# Ensure your code compiles locally and all tests pass (Green).
# Do '''NOT''' upload your <code>build/</code> directory or any generated HTML files.
# Select the following files from your workspace:
#* <code>CMakeLists.txt</code>
#* <code>include/ISensor.h</code>
#* <code>include/OvenController.h</code>
#* <code>src/OvenController.cpp</code>
#* <code>tests/test_oven.cpp</code>
# Package these files into a single <code>.zip</code> archive (maintaining the folder structure).
# Go to the Lab 4 assignment on Moodle and upload your <code>.zip</code> file into the VPL submission portal.
# Click the '''Evaluate''' button.

The VPL server will automatically compile your CMake project, execute your Google Tests, and run <code>gcovr</code>. Your grade will be calculated based on the number of passing tests and the percentage of branch coverage achieved.

SDPT Lab 4

2026-03-23T13:27:18Z

Rhobincu: Pagină nouă: = Lab 4: Software Verification - TDD, Mocking, and Code Coverage = == Introduction == In traditional embedded systems, testing involves compiling code, flashing it to a board, and...

= Lab 4: Software Verification - TDD, Mocking, and Code Coverage =

== Introduction ==
In traditional embedded systems, testing involves compiling code, flashing it to a board, and physically observing the hardware. This is slow, expensive, and scales poorly. Today, we implement "Shift-Left Testing." We will verify our C++ logic on our Host PC using automated frameworks before it ever touches a microcontroller.

=== Goals ===
* Integrate Google Test and Google Mock via CMake.
* Write Unit Tests using the AAA (Arrange, Act, Assert) pattern.
* Use Dependency Injection to decouple business logic from hardware registers.
* Simulate hardware interactions using Google Mock (GMock).
* Generate interactive HTML Code Coverage reports using <code>gcovr</code>.

== Part 1: Theoretical Reference ==
''Use this section as a reference manual to complete the challenges in Part 2.''

=== 1.1 Google Test & Mock Cheat Sheet ===
'''Basic Assertions:'''
* <code>EXPECT_EQ(actual, expected);</code> (Non-fatal equality check)
* <code>EXPECT_FLOAT_EQ(actual, expected);</code> (Safe float comparison)
* <code>EXPECT_TRUE(condition);</code>

'''Mocking an Interface (GMock):'''
<pre>
class MockSensor : public ISensor {
public:
// MOCK_METHOD(ReturnType, MethodName, (Arguments), (override));
MOCK_METHOD(float, read_temperature, (), (override));
};
</pre>

'''Setting Mock Expectations:'''
<pre>
MockSensor fake_sensor;
// Program the mock to return 45.0 exactly twice.
EXPECT_CALL(fake_sensor, read_temperature())
.Times(2)
.WillRepeatedly(testing::Return(45.0f));
</pre>

=== 1.2 CMake Debug & Coverage Setup ===
Coverage mathematically requires a completely unoptimized binary mapping exactly to your source code lines.
<pre>
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
target_compile_options(my_target PRIVATE -O0 -g --coverage)
target_link_options(my_target PRIVATE --coverage)
endif()
</pre>

=== 1.3 Running gcovr ===
Execute this from inside your <code>build/</code> directory after running the tests:
<pre>
gcovr -r ../ . --html --html-details -o coverage.html -e ".*_deps.*"
</pre>

== Part 2: The Challenges ==

=== Setup: The Raw Materials ===
You are building the safety controller for an industrial oven. It must read temperatures from an I2C sensor and trigger a physical alarm if it overheats.

Create a new workspace (<code>sdpt-lab4</code>). Create <code>include/</code> and <code>src/</code> directories. Populate them with these three files:

'''<code>include/ISensor.h</code>''' (The Hardware Interface)
<pre>
#pragma once

// Pure virtual interface. We DO NOT implement hardware logic here.
class ISensor {
public:
virtual float read_temperature() = 0;
virtual ~ISensor() = default;
};
</pre>

'''<code>include/OvenController.h</code>''' (The Logic Module)
<pre>
#pragma once
#include "ISensor.h"

class OvenController {
private:
ISensor* temp_sensor;
bool alarm_active;
float max_safe_temp;

public:
// Constructor uses Dependency Injection!
OvenController(ISensor* sensor, float safe_limit = 250.0f);

void check_safety();
bool is_alarm_active() const;

// Pure math function
static float raw_adc_to_celsius(int adc_value);
};
</pre>

'''<code>src/OvenController.cpp</code>''' (The Buggy Implementation)
<pre>
#include "../include/OvenController.h"

OvenController::OvenController(ISensor* sensor, float safe_limit)
: temp_sensor(sensor), alarm_active(false), max_safe_temp(safe_limit) {}

void OvenController::check_safety() {
float current_temp = temp_sensor->read_temperature();

// BUG 1: It only triggers if STRICTLY greater. What if it equals the limit?
if (current_temp > max_safe_temp) {
alarm_active = true;
} else {
alarm_active = false;
}
}

bool OvenController::is_alarm_active() const {
return alarm_active;
}

float OvenController::raw_adc_to_celsius(int adc_value) {
// BUG 2: Integer division truncates the decimal! (e.g., 5/2 = 2, not 2.5)
return (adc_value / 4095) * 330.0f;
}
</pre>

=== Challenge 1: The Verification Build System (Estimated: 20 mins) ===
We need a build system that fetches Google Test and compiles our code with coverage instrumentation.
'''Your Task:'''
# Create a <code>CMakeLists.txt</code> in the root directory.
# Build a static library named <code>oven_lib</code> containing <code>src/OvenController.cpp</code>.
# Use <code>FetchContent</code> to pull Google Test (<code>https://github.com/google/googletest.git</code>, tag <code>v1.13.0</code>).
# Create an executable named <code>unit_tests</code>. (You will create <code>tests/test_oven.cpp</code> in the next step).
# Link <code>oven_lib</code>, <code>gtest_main</code>, and <code>gmock</code> to your test executable.
# Add the CMake logic to inject <code>-O0 -g --coverage</code> ONLY if the build type is "Debug".

'''Verification:''' Run <code>cmake -DCMAKE_BUILD_TYPE=Debug ..</code> inside your build folder. It must configure without errors and download GTest.

=== Challenge 2: Pure Math TDD (Estimated: 25 mins) ===
Let's catch the integer division bug using the Red-Green-Refactor cycle.
'''Your Task:'''
# Create a <code>tests/</code> directory and a <code>tests/test_oven.cpp</code> file.
# Include <code><gtest/gtest.h></code> and your <code>OvenController.h</code>.
# Write a <code>TEST(MathTest, ConvertsADCToCelsius)</code>.
# Use <code>EXPECT_FLOAT_EQ</code> to assert that an ADC value of <code>2047</code> (roughly half of 4095) returns approximately <code>164.957f</code>.
# Compile and run <code>./unit_tests</code>. (Watch it fail! This is the RED phase).
# Refactor <code>OvenController.cpp</code> to fix the integer division bug. Recompile. (Watch it pass! This is the GREEN phase).

=== Challenge 3: Hardware Mocking (Estimated: 40 mins) ===
We need to test <code>check_safety()</code>, but we are on a PC. We have no I2C hardware. We must mock the <code>ISensor</code>.
'''Your Task:'''
# In your test file, include <code><gmock/gmock.h></code>.
# Create a <code>MockSensor</code> class that inherits from <code>ISensor</code>. Use <code>MOCK_METHOD</code> to mock <code>read_temperature</code>.
# Write a <code>TEST(SafetyTest, TriggersAlarmOnOverheat)</code>.
#* '''Arrange:''' Instantiate the MockSensor. Instantiate the OvenController, injecting the mock sensor into it with a safe limit of 250.0f.
#* '''Expectation:''' Program the mock to return <code>260.0f</code> when called.
#* '''Act:''' Call <code>check_safety()</code>.
#* '''Assert:''' Expect that <code>is_alarm_active()</code> is true.
# Write a second test: <code>TEST(SafetyTest, TriggersAlarmExactlyAtLimit)</code>.
#* Program the mock to return exactly <code>250.0f</code>.
#* Run the test. It will FAIL due to Bug 1. Fix the production code so it triggers on `>=`.

=== Challenge 4: The Coverage Report (Estimated: 15 mins) ===
Did we test every branch of our code? Let's prove it mathematically.
'''Your Task:'''
# Ensure you have run <code>./unit_tests</code> at least once so the <code>.gcda</code> files are generated.
# Run the <code>gcovr</code> command provided in the Theoretical Reference section.
# Open the resulting <code>coverage.html</code> file in your web browser.

'''Verification:''' Click on the <code>OvenController.cpp</code> file in the HTML report. You should see 100% line coverage and 100% branch coverage (green lines). If you have red lines, you are missing a test case!

== Lab Evaluation ==
To receive full credit, call the professor/TA to your workstation and demonstrate:
# Run <code>./unit_tests</code>. All tests must pass (Green).
# Show your test code, explaining how Dependency Injection allowed you to pass the <code>MockSensor</code> into the controller.
# Open your <code>coverage.html</code> report in the browser, demonstrating 100% branch coverage for the <code>OvenController.cpp</code> file.

Software Development Process and Testing

2026-03-23T13:26:31Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]
* [[SDPT Lab 3]]
* [[SDPT Lab 4]]

SDPT Lab 3

2026-03-16T17:07:57Z

Rhobincu:

= Lab 3: Build Automation - Makefiles and Modern CMake =

== Introduction ==
In professional embedded development, clicking a "Build" button in an IDE is a luxury you rarely have. When working with Embedded Linux, RTOS environments, or CI/CD pipelines, you must define exactly how your source code is translated into machine code.

This lab transitions you from manual terminal commands to scalable build automation.

=== Goals ===
* Understand the C++ compilation pipeline (Preprocessing $\rightarrow$ Compilation $\rightarrow$ Linking).
* Master GNU Make: pattern rules, automatic variables, and header dependency generation.
* Master Modern CMake: out-of-source builds, targets, and static libraries.
* Integrate remote third-party libraries using CMake <code>FetchContent</code>.

== Part 1: Theoretical Reference ==
''Use this section as a reference manual to complete the tasks in Part 2.''

=== 1.1 GNU Make Fundamentals ===
Make tracks file modification timestamps to avoid recompiling code that hasn't changed. A <code>Makefile</code> consists of rules:
<syntaxhighlight lang="make">
target: dependencies
<TAB> command
</syntaxhighlight>
''(Note: Makefiles strictly require a real TAB character for indentation, not spaces!)''

'''Automatic Variables:'''
Make provides shortcuts to avoid typing duplicate filenames:
* <code>$@</code> : The target filename.
* <code>$<</code> : The first dependency.
* <code>$^</code> : All dependencies (space-separated).

'''Pattern Rules:'''
Instead of writing a rule for every file, use a pattern template:
<syntaxhighlight lang="make">
%.o: %.cpp
$(CXX) $(CXXFLAGS) -c $< -o $@
</syntaxhighlight>

'''GCC Auto-Dependencies (The Header Problem):'''
If you change a <code>.h</code> file, Make won't normally detect it because object files depend on <code>.cpp</code> files. We ask GCC to generate dependency (<code>.d</code>) files for us:
* Add <code>-MMD -MP</code> to your <code>CXXFLAGS</code>.
* Include the generated files at the bottom of your Makefile using: <code>-include $(DEPS)</code>

=== 1.2 Modern CMake Fundamentals ===
CMake is a meta-build system. It generates Makefiles (or Ninja files, or Visual Studio solutions) based on a high-level <code>CMakeLists.txt</code> script. Modern CMake is "Target-Based"—you define targets (executables/libraries) and attach properties to them.

'''Core Commands:'''
<syntaxhighlight lang="cmake">
cmake_minimum_required(VERSION 3.10)
project(MyProject CXX)

# Build an executable from source
add_executable(my_app main.cpp)

# Build a static library (.a archive)
add_library(my_driver STATIC driver.cpp)

# Define where a target should look for header files
target_include_directories(my_driver PUBLIC include/)

# Link a library to an executable
target_link_libraries(my_app PRIVATE my_driver)
</syntaxhighlight>

'''Out-of-Source Builds:'''
Never pollute your source directory with binaries. Always build in a separate folder:
<syntaxhighlight lang="bash">
mkdir build && cd build
cmake ..
make
</syntaxhighlight>

'''Fetching External Libraries:'''
CMake can download libraries directly from Git during the configuration phase:
<syntaxhighlight lang="cmake">
include(FetchContent)
FetchContent_Declare(
json_lib
GIT_REPOSITORY https://github.com/nlohmann/json.git
GIT_TAG v3.11.2
)
FetchContent_MakeAvailable(json_lib)
</syntaxhighlight>

=== 1.3 Useful Resources ===
* [https://www.gnu.org/software/make/manual/make.html GNU Make Manual]
* [https://cmake.org/cmake/help/latest/ CMake Official Documentation]

== Part 2: The Challenges ==

=== Setup: The Raw Materials ===
Create a new directory for this lab (<code>sdpt-lab3</code>). Inside, create an <code>include/</code> directory and a <code>src/</code> directory. Populate them with the following three files to simulate an IoT sensor node.

'''<code>include/sensor.h</code>'''
<syntaxhighlight lang="cpp">
#pragma once

struct SensorData {
int temperature;
int humidity;
};

void init_sensor();
SensorData read_sensor();
</syntaxhighlight>

'''<code>src/sensor.cpp</code>'''
<syntaxhighlight lang="cpp">
#include <iostream>
#include "../include/sensor.h"

void init_sensor() {
std::cout << "[Hardware] I2C Sensor Initialized." << std::endl;
}

SensorData read_sensor() {
return {24, 60};
}
</syntaxhighlight>

'''<code>src/main.cpp</code>'''
<syntaxhighlight lang="cpp">
#include <iostream>
#include "../include/sensor.h"

int main() {
std::cout << "Starting IoT Node..." << std::endl;
init_sensor();

SensorData data = read_sensor();
std::cout << "Temp: " << data.temperature << "C, Hum: " << data.humidity << "%" << std::endl;

return 0;
}
</syntaxhighlight>

=== Challenge 1: The Scalable Makefile (Estimated time: 25 mins) ===
'''Your Task:''' Write a <code>Makefile</code> in the root directory that compiles these files into an executable named <code>iot_node.bin</code>.
* Do '''not''' hardcode the <code>.cpp</code> file names. Use the <code>wildcard</code> function to find them dynamically.
* Use variables for the compiler (<code>CXX</code>) and flags (<code>CXXFLAGS</code>).
* Use Pattern Rules and Automatic Variables to compile <code>.cpp</code> to <code>.o</code>.
* Implement GCC header dependency tracking (<code>-MMD -MP</code>).

'''Verification:'''
# Run <code>make</code>. It should compile successfully.
# Run <code>make</code> again immediately. It should say "Nothing to be done".
# Open <code>include/sensor.h</code> and add a dummy integer to the <code>SensorData</code> struct. Run <code>make</code> again. It MUST recompile both <code>.cpp</code> files automatically. If it doesn't, your dependency tracking is broken.

=== Challenge 2: Migrating to CMake (Estimated time: 20 mins) ===
Makefiles are not cross-platform. We are moving to CMake.
'''Your Task:'''
# Run <code>make clean</code> (or manually delete all generated <code>.o</code>, <code>.d</code>, and <code>.bin</code> files).
# Create a <code>CMakeLists.txt</code> file to build the exact same executable.
# Set the C++ standard to C++14.
# Perform an '''Out-of-Source build''' using a <code>build/</code> directory.

'''Verification:'''
Your root directory should contain only your source files and the <code>CMakeLists.txt</code>. Inside the <code>build/</code> directory, running <code>make</code> should yield the executable.

=== Challenge 3: Modular Architecture (Estimated time: 25 mins) ===
Dumping all source files into a single executable is bad practice. Hardware drivers should be isolated into static libraries.
'''Your Task:''' Modify your <code>CMakeLists.txt</code>.
# Remove <code>src/sensor.cpp</code> from your executable target.
# Create a new STATIC library target named <code>sensor_driver</code> from <code>src/sensor.cpp</code>.
# Attach the <code>include/</code> directory to this library target using <code>target_include_directories</code>.
# Link the <code>sensor_driver</code> library to your main executable.

'''Verification:'''
Run <code>make</code> inside the build folder. You must see it compile <code>libsensor_driver.a</code> first, and then link it to the main executable.

=== Challenge 4: Third-Party Git Dependencies (Estimated time: 30 mins) ===
Our IoT node needs to transmit its data as a JSON payload, but writing a JSON parser from scratch is inefficient.
'''Your Task:'''
# Use CMake's <code>FetchContent</code> module to download the popular "Nlohmann JSON" library directly from GitHub.
#* Repo: <code>https://github.com/nlohmann/json.git</code>
#* Tag: <code>v3.11.2</code>
# Link the imported target (<code>nlohmann_json::nlohmann_json</code>) to your main executable.
# Modify <code>main.cpp</code> to include <code><nlohmann/json.hpp></code>. Serialize your <code>SensorData</code> into a JSON object and print it to the console using <code>.dump(4)</code>.

'''Verification:'''
Running your executable should print a perfectly formatted, multi-line JSON string representing your sensor data. Check <code>build/_deps/</code> to see the downloaded source code.

== Lab Evaluation ==
To receive full credit, submit the following elements on Moodle:
# Final version of the Makefile.
# Final version of the CMakeLists.txt.
# Screenshot of the console output of your executable printing the JSON payload.

SDPT Lab 3

2026-03-15T22:46:16Z

Rhobincu:

= Lab 3: Build Automation - Makefiles and Modern CMake =

== Introduction ==
In professional embedded development, clicking a "Build" button in an IDE is a luxury you rarely have. When working with Embedded Linux, RTOS environments, or CI/CD pipelines, you must define exactly how your source code is translated into machine code.

This lab transitions you from manual terminal commands to scalable build automation.

=== Goals ===
* Understand the C++ compilation pipeline (Preprocessing $\rightarrow$ Compilation $\rightarrow$ Linking).
* Master GNU Make: pattern rules, automatic variables, and header dependency generation.
* Master Modern CMake: out-of-source builds, targets, and static libraries.
* Integrate remote third-party libraries using CMake <code>FetchContent</code>.

== Part 1: Theoretical Reference ==
''Use this section as a reference manual to complete the tasks in Part 2.''

=== 1.1 GNU Make Fundamentals ===
Make tracks file modification timestamps to avoid recompiling code that hasn't changed. A <code>Makefile</code> consists of rules:
<syntaxhighlight lang="make">
target: dependencies
<TAB> command
</syntaxhighlight>
''(Note: Makefiles strictly require a real TAB character for indentation, not spaces!)''

'''Automatic Variables:'''
Make provides shortcuts to avoid typing duplicate filenames:
* <code>$@</code> : The target filename.
* <code>$<</code> : The first dependency.
* <code>$^</code> : All dependencies (space-separated).

'''Pattern Rules:'''
Instead of writing a rule for every file, use a pattern template:
<syntaxhighlight lang="make">
%.o: %.cpp
$(CXX) $(CXXFLAGS) -c $< -o $@
</syntaxhighlight>

'''GCC Auto-Dependencies (The Header Problem):'''
If you change a <code>.h</code> file, Make won't normally detect it because object files depend on <code>.cpp</code> files. We ask GCC to generate dependency (<code>.d</code>) files for us:
* Add <code>-MMD -MP</code> to your <code>CXXFLAGS</code>.
* Include the generated files at the bottom of your Makefile using: <code>-include $(DEPS)</code>

=== 1.2 Modern CMake Fundamentals ===
CMake is a meta-build system. It generates Makefiles (or Ninja files, or Visual Studio solutions) based on a high-level <code>CMakeLists.txt</code> script. Modern CMake is "Target-Based"—you define targets (executables/libraries) and attach properties to them.

'''Core Commands:'''
<syntaxhighlight lang="cmake">
cmake_minimum_required(VERSION 3.10)
project(MyProject CXX)

# Build an executable from source
add_executable(my_app main.cpp)

# Build a static library (.a archive)
add_library(my_driver STATIC driver.cpp)

# Define where a target should look for header files
target_include_directories(my_driver PUBLIC include/)

# Link a library to an executable
target_link_libraries(my_app PRIVATE my_driver)
</syntaxhighlight>

'''Out-of-Source Builds:'''
Never pollute your source directory with binaries. Always build in a separate folder:
<syntaxhighlight lang="bash">
mkdir build && cd build
cmake ..
make
</syntaxhighlight>

'''Fetching External Libraries:'''
CMake can download libraries directly from Git during the configuration phase:
<syntaxhighlight lang="cmake">
include(FetchContent)
FetchContent_Declare(
json_lib
GIT_REPOSITORY https://github.com/nlohmann/json.git
GIT_TAG v3.11.2
)
FetchContent_MakeAvailable(json_lib)
</syntaxhighlight>

=== 1.3 Useful Resources ===
* [https://www.gnu.org/software/make/manual/make.html GNU Make Manual]
* [https://cmake.org/cmake/help/latest/ CMake Official Documentation]

== Part 2: The Challenges ==

=== Setup: The Raw Materials ===
Create a new directory for this lab (<code>sdpt-lab3</code>). Inside, create an <code>include/</code> directory and a <code>src/</code> directory. Populate them with the following three files to simulate an IoT sensor node.

'''<code>include/sensor.h</code>'''
<syntaxhighlight lang="cpp">
#pragma once

struct SensorData {
int temperature;
int humidity;
};

void init_sensor();
SensorData read_sensor();
</syntaxhighlight>

'''<code>src/sensor.cpp</code>'''
<syntaxhighlight lang="cpp">
#include <iostream>
#include "../include/sensor.h"

void init_sensor() {
std::cout << "[Hardware] I2C Sensor Initialized." << std::endl;
}

SensorData read_sensor() {
return {24, 60};
}
</syntaxhighlight>

'''<code>src/main.cpp</code>'''
<syntaxhighlight lang="cpp">
#include <iostream>
#include "../include/sensor.h"

int main() {
std::cout << "Starting IoT Node..." << std::endl;
init_sensor();

SensorData data = read_sensor();
std::cout << "Temp: " << data.temperature << "C, Hum: " << data.humidity << "%" << std::endl;

return 0;
}
</syntaxhighlight>

=== Challenge 1: The Scalable Makefile (Estimated time: 25 mins) ===
'''Your Task:''' Write a <code>Makefile</code> in the root directory that compiles these files into an executable named <code>iot_node.bin</code>.
* Do '''not''' hardcode the <code>.cpp</code> file names. Use the <code>wildcard</code> function to find them dynamically.
* Use variables for the compiler (<code>CXX</code>) and flags (<code>CXXFLAGS</code>).
* Use Pattern Rules and Automatic Variables to compile <code>.cpp</code> to <code>.o</code>.
* Implement GCC header dependency tracking (<code>-MMD -MP</code>).

'''Verification:'''
# Run <code>make</code>. It should compile successfully.
# Run <code>make</code> again immediately. It should say "Nothing to be done".
# Open <code>include/sensor.h</code> and add a dummy integer to the <code>SensorData</code> struct. Run <code>make</code> again. It MUST recompile both <code>.cpp</code> files automatically. If it doesn't, your dependency tracking is broken.

=== Challenge 2: Migrating to CMake (Estimated time: 20 mins) ===
Makefiles are not cross-platform. We are moving to CMake.
'''Your Task:'''
# Run <code>make clean</code> (or manually delete all generated <code>.o</code>, <code>.d</code>, and <code>.bin</code> files).
# Create a <code>CMakeLists.txt</code> file to build the exact same executable.
# Set the C++ standard to C++14.
# Perform an '''Out-of-Source build''' using a <code>build/</code> directory.

'''Verification:'''
Your root directory should contain only your source files and the <code>CMakeLists.txt</code>. Inside the <code>build/</code> directory, running <code>make</code> should yield the executable.

=== Challenge 3: Modular Architecture (Estimated time: 25 mins) ===
Dumping all source files into a single executable is bad practice. Hardware drivers should be isolated into static libraries.
'''Your Task:''' Modify your <code>CMakeLists.txt</code>.
# Remove <code>src/sensor.cpp</code> from your executable target.
# Create a new STATIC library target named <code>sensor_driver</code> from <code>src/sensor.cpp</code>.
# Attach the <code>include/</code> directory to this library target using <code>target_include_directories</code>.
# Link the <code>sensor_driver</code> library to your main executable.

'''Verification:'''
Run <code>make</code> inside the build folder. You must see it compile <code>libsensor_driver.a</code> first, and then link it to the main executable.

=== Challenge 4: Third-Party Git Dependencies (Estimated time: 30 mins) ===
Our IoT node needs to transmit its data as a JSON payload, but writing a JSON parser from scratch is inefficient.
'''Your Task:'''
# Use CMake's <code>FetchContent</code> module to download the popular "Nlohmann JSON" library directly from GitHub.
#* Repo: <code>https://github.com/nlohmann/json.git</code>
#* Tag: <code>v3.11.2</code>
# Link the imported target (<code>nlohmann_json::nlohmann_json</code>) to your main executable.
# Modify <code>main.cpp</code> to include <code><nlohmann/json.hpp></code>. Serialize your <code>SensorData</code> into a JSON object and print it to the console using <code>.dump(4)</code>.

'''Verification:'''
Running your executable should print a perfectly formatted, multi-line JSON string representing your sensor data. Check <code>build/_deps/</code> to see the downloaded source code.

== Lab Evaluation ==
To receive full credit, call the professor/TA to your workstation and demonstrate:
# The GCC dependency tracking working in Challenge 1 (changing a header triggers a recompile).
# The clean root directory, proving an Out-of-Source build.
# The <code>libsensor_driver.a</code> static library file inside your build directory.
# The console output of your executable printing the JSON payload.

SDPT Lab 3

2026-03-15T22:43:20Z

Rhobincu:

= Lab 3: Build Automation - Makefiles and Modern CMake =

== Introduction ==
In professional embedded development, clicking a "Build" button in an IDE is a luxury you rarely have. When working with Embedded Linux, RTOS environments, or CI/CD pipelines, you must define exactly how your source code is translated into machine code.

This lab transitions you from manual terminal commands to scalable build automation.

=== Goals ===
* Understand the C++ compilation pipeline (Preprocessing $\rightarrow$ Compilation $\rightarrow$ Linking).
* Master GNU Make: pattern rules, automatic variables, and header dependency generation.
* Master Modern CMake: out-of-source builds, targets, and static libraries.
* Integrate remote third-party libraries using CMake <code>FetchContent</code>.

---

== Part 1: Theoretical Reference ==
''Use this section as a reference manual to complete the tasks in Part 2.''

=== 1.1 GNU Make Fundamentals ===
Make tracks file modification timestamps to avoid recompiling code that hasn't changed. A <code>Makefile</code> consists of rules:
<syntaxhighlight lang="make">
target: dependencies
<TAB> command
</syntaxhighlight>
''(Note: Makefiles strictly require a real TAB character for indentation, not spaces!)''

'''Automatic Variables:'''
Make provides shortcuts to avoid typing duplicate filenames:
* <code>$@</code> : The target filename.
* <code>$<</code> : The first dependency.
* <code>$^</code> : All dependencies (space-separated).

'''Pattern Rules:'''
Instead of writing a rule for every file, use a pattern template:
<syntaxhighlight lang="make">
%.o: %.cpp
$(CXX) $(CXXFLAGS) -c $< -o $@
</syntaxhighlight>

'''GCC Auto-Dependencies (The Header Problem):'''
If you change a <code>.h</code> file, Make won't normally detect it because object files depend on <code>.cpp</code> files. We ask GCC to generate dependency (<code>.d</code>) files for us:
* Add <code>-MMD -MP</code> to your <code>CXXFLAGS</code>.
* Include the generated files at the bottom of your Makefile using: <code>-include $(DEPS)</code>

=== 1.2 Modern CMake Fundamentals ===
CMake is a meta-build system. It generates Makefiles (or Ninja files, or Visual Studio solutions) based on a high-level <code>CMakeLists.txt</code> script. Modern CMake is "Target-Based"—you define targets (executables/libraries) and attach properties to them.

'''Core Commands:'''
<syntaxhighlight lang="cmake">
cmake_minimum_required(VERSION 3.10)
project(MyProject CXX)

# Build an executable from source
add_executable(my_app main.cpp)

# Build a static library (.a archive)
add_library(my_driver STATIC driver.cpp)

# Define where a target should look for header files
target_include_directories(my_driver PUBLIC include/)

# Link a library to an executable
target_link_libraries(my_app PRIVATE my_driver)
</syntaxhighlight>

'''Out-of-Source Builds:'''
Never pollute your source directory with binaries. Always build in a separate folder:
<syntaxhighlight lang="bash">
mkdir build && cd build
cmake ..
make
</syntaxhighlight>

'''Fetching External Libraries:'''
CMake can download libraries directly from Git during the configuration phase:
<syntaxhighlight lang="cmake">
include(FetchContent)
FetchContent_Declare(
json_lib
GIT_REPOSITORY https://github.com/nlohmann/json.git
GIT_TAG v3.11.2
)
FetchContent_MakeAvailable(json_lib)
</syntaxhighlight>

=== 1.3 Useful Resources ===
* [https://www.gnu.org/software/make/manual/make.html GNU Make Manual]
* [https://cmake.org/cmake/help/latest/ CMake Official Documentation]

---

== Part 2: The Challenges ==

=== Setup: The Raw Materials ===
Create a new directory for this lab (<code>sdpt-lab3</code>). Inside, create an <code>include/</code> directory and a <code>src/</code> directory. Populate them with the following three files to simulate an IoT sensor node.

'''<code>include/sensor.h</code>'''
<syntaxhighlight lang="cpp">
#pragma once

struct SensorData {
int temperature;
int humidity;
};

void init_sensor();
SensorData read_sensor();
</syntaxhighlight>

'''<code>src/sensor.cpp</code>'''
<syntaxhighlight lang="cpp">
#include <iostream>
#include "../include/sensor.h"

void init_sensor() {
std::cout << "[Hardware] I2C Sensor Initialized." << std::endl;
}

SensorData read_sensor() {
return {24, 60};
}
</syntaxhighlight>

'''<code>src/main.cpp</code>'''
<syntaxhighlight lang="cpp">
#include <iostream>
#include "../include/sensor.h"

int main() {
std::cout << "Starting IoT Node..." << std::endl;
init_sensor();

SensorData data = read_sensor();
std::cout << "Temp: " << data.temperature << "C, Hum: " << data.humidity << "%" << std::endl;

return 0;
}
</syntaxhighlight>

---

=== Challenge 1: The Scalable Makefile (Estimated time: 25 mins) ===
'''Your Task:''' Write a <code>Makefile</code> in the root directory that compiles these files into an executable named <code>iot_node.bin</code>.
* Do '''not''' hardcode the <code>.cpp</code> file names. Use the <code>wildcard</code> function to find them dynamically.
* Use variables for the compiler (<code>CXX</code>) and flags (<code>CXXFLAGS</code>).
* Use Pattern Rules and Automatic Variables to compile <code>.cpp</code> to <code>.o</code>.
* Implement GCC header dependency tracking (<code>-MMD -MP</code>).

'''Verification:'''
# Run <code>make</code>. It should compile successfully.
# Run <code>make</code> again immediately. It should say "Nothing to be done".
# Open <code>include/sensor.h</code> and add a dummy integer to the <code>SensorData</code> struct. Run <code>make</code> again. It MUST recompile both <code>.cpp</code> files automatically. If it doesn't, your dependency tracking is broken.

---

=== Challenge 2: Migrating to CMake (Estimated time: 20 mins) ===
Makefiles are not cross-platform. We are moving to CMake.
'''Your Task:'''
# Run <code>make clean</code> (or manually delete all generated <code>.o</code>, <code>.d</code>, and <code>.bin</code> files).
# Create a <code>CMakeLists.txt</code> file to build the exact same executable.
# Set the C++ standard to C++14.
# Perform an '''Out-of-Source build''' using a <code>build/</code> directory.

'''Verification:'''
Your root directory should contain only your source files and the <code>CMakeLists.txt</code>. Inside the <code>build/</code> directory, running <code>make</code> should yield the executable.

---

=== Challenge 3: Modular Architecture (Estimated time: 25 mins) ===
Dumping all source files into a single executable is bad practice. Hardware drivers should be isolated into static libraries.
'''Your Task:''' Modify your <code>CMakeLists.txt</code>.
# Remove <code>src/sensor.cpp</code> from your executable target.
# Create a new STATIC library target named <code>sensor_driver</code> from <code>src/sensor.cpp</code>.
# Attach the <code>include/</code> directory to this library target using <code>target_include_directories</code>.
# Link the <code>sensor_driver</code> library to your main executable.

'''Verification:'''
Run <code>make</code> inside the build folder. You must see it compile <code>libsensor_driver.a</code> first, and then link it to the main executable.

---

=== Challenge 4: Third-Party Git Dependencies (Estimated time: 30 mins) ===
Our IoT node needs to transmit its data as a JSON payload, but writing a JSON parser from scratch is inefficient.
'''Your Task:'''
# Use CMake's <code>FetchContent</code> module to download the popular "Nlohmann JSON" library directly from GitHub.
#* Repo: <code>https://github.com/nlohmann/json.git</code>
#* Tag: <code>v3.11.2</code>
# Link the imported target (<code>nlohmann_json::nlohmann_json</code>) to your main executable.
# Modify <code>main.cpp</code> to include <code><nlohmann/json.hpp></code>. Serialize your <code>SensorData</code> into a JSON object and print it to the console using <code>.dump(4)</code>.

'''Verification:'''
Running your executable should print a perfectly formatted, multi-line JSON string representing your sensor data. Check <code>build/_deps/</code> to see the downloaded source code.

---

== Lab Evaluation ==
To receive full credit, call the professor/TA to your workstation and demonstrate:
# The GCC dependency tracking working in Challenge 1 (changing a header triggers a recompile).
# The clean root directory, proving an Out-of-Source build.
# The <code>libsensor_driver.a</code> static library file inside your build directory.
# The console output of your executable printing the JSON payload.

SDPT Lab 3

2026-03-15T22:37:31Z

Rhobincu: Pagină nouă: = Lab 3: Build Systems - From GNU Make to Modern CMake = == Introduction == In Week 2, we solved the human collaboration problem using Git. Today, we solve the compilation scaling...

= Lab 3: Build Systems - From GNU Make to Modern CMake =

== Introduction ==
In Week 2, we solved the human collaboration problem using Git. Today, we solve the compilation scaling problem.

As embedded projects grow from a single file to hundreds of files with external dependencies (like cryptography or networking libraries), clicking a "Build" button in an IDE or typing <code>g++ main.cpp</code> in the terminal is no longer viable. By the end of this 2-hour lab, you will have:
# Written a scalable GNU Makefile using pattern rules and automatic variables.
# Solved the "Header Dependency Problem" using GCC's <code>-MMD</code> flags.
# Migrated the project to Modern CMake.
# Enforced clean "Out-of-Source" builds.
# Built a static hardware driver library and linked it to an executable.
# Automatically downloaded and linked a 3rd-party library directly from GitHub using CMake's <code>FetchContent</code>.

'''Requirement:''' You may work individually or with your partner from last week.

---

== Part 1: Project Setup and The GNU Make Baseline (30 Minutes) ==
First, we need some source code to compile. We will simulate an IoT sensor node.

=== 1. Create the Project Workspace ===
Open your terminal and create a new directory:
<pre>
mkdir sdpt-lab3-builds
cd sdpt-lab3-builds
mkdir src include
</pre>

=== 2. Create the Source Files ===
Create a header file <code>include/sensor.h</code>:
<pre>
#ifndef SENSOR_H
#define SENSOR_H

struct SensorData {
int temperature;
int humidity;
};

void init_sensor();
SensorData read_sensor();

#endif
</pre>

Create the implementation file <code>src/sensor.cpp</code>:
<pre>
#include <iostream>
#include "../include/sensor.h"

void init_sensor() {
std::cout << "[Hardware] I2C Sensor Initialized." << std::endl;
}

SensorData read_sensor() {
SensorData data;
data.temperature = 24;
data.humidity = 60;
return data;
}
</pre>

Create the main application <code>src/main.cpp</code>:
<pre>
#include <iostream>
#include "../include/sensor.h"

int main() {
std::cout << "Starting IoT Node..." << std::endl;
init_sensor();

SensorData current_data = read_sensor();
std::cout << "Temp: " << current_data.temperature << "C, Hum: " << current_data.humidity << "%" << std::endl;

return 0;
}
</pre>

=== 3. Write the Scalable Makefile ===
In the root directory (<code>sdpt-lab3-builds/</code>), create a file named exactly <code>Makefile</code>.
''Warning: You MUST use an actual TAB character for the indented lines, not spaces!''

<pre>
CXX = g++
CXXFLAGS = -Wall -Wextra -O2 -MMD -MP
TARGET = firmware.bin

# Dynamically find all .cpp files in the src/ directory
SRCS = $(wildcard src/*.cpp)

# String substitution: convert .cpp list to .o list
OBJS = $(SRCS:.cpp=.o)

# Create a list of .d (dependency) files
DEPS = $(OBJS:.o=.d)

# Default rule
all: $(TARGET)

# Linker rule using automatic variables ($^ = all dependencies, $@ = target)
$(TARGET): $(OBJS)
$(CXX) $^ -o $@

# Pattern rule to compile any .cpp into a .o file ($< = first dependency)
%.o: %.cpp
$(CXX) $(CXXFLAGS) -c $< -o $@

# Clean rule to remove binaries
clean:
rm -f $(OBJS) $(DEPS) $(TARGET)

# Include the auto-generated GCC dependencies
-include $(DEPS)
</pre>

=== 4. Test and Inspect the Build ===
Run the build:
<pre>
make
./firmware.bin
</pre>
Now, look inside your <code>src/</code> folder. Run <code>ls src/</code>.
Notice the <code>.d</code> files? Open <code>src/main.d</code> in a text editor. You will see that GCC automatically wrote a Makefile rule proving that <code>main.o</code> depends on <code>sensor.h</code>. This is how Make knows to recompile <code>main.cpp</code> if you only change the header file!

---

== Part 2: Migrating to Modern CMake (30 Minutes) ==
Makefiles are great, but they leave <code>.o</code> and <code>.d</code> files scattered all over our source code, and they are not cross-platform. Let's upgrade.

=== 1. Clean up the Make artifacts ===
Run the clean rule to delete all the generated binaries from Part 1.
<pre>
make clean
</pre>

=== 2. Write the CMakeLists.txt ===
In the root directory, create a file named <code>CMakeLists.txt</code>:

<pre>
cmake_minimum_required(VERSION 3.10)
project(IoTNode CXX)

set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# Define the executable and its source files
add_executable(firmware src/main.cpp src/sensor.cpp)

# Tell CMake where to look for header files
target_include_directories(firmware PRIVATE include/)
</pre>

=== 3. The Out-of-Source Build ===
We will never compile in the root directory again.
<pre>
mkdir build
cd build

# Tell CMake to read the parent directory and generate the build system
cmake ..

# Execute the build
make
</pre>
Run your program: <code>./firmware</code>. Notice that your <code>src/</code> directory is completely clean. All binaries are safely isolated inside the <code>build/</code> folder.

---

== Part 3: Modular Architecture (Static Libraries) (30 Minutes) ==
In professional embedded development, we don't dump all source files into the executable. We build independent, reusable Static Libraries (<code>.a</code> files) for hardware drivers.

=== 1. Refactor CMakeLists.txt ===
Go back to your root directory and open <code>CMakeLists.txt</code>. Rewrite it to decouple the sensor driver from the main application:

<pre>
cmake_minimum_required(VERSION 3.10)
project(IoTNode CXX)

set(CMAKE_CXX_STANDARD 14)

# 1. Build the sensor driver as a STATIC library
add_library(sensor_lib STATIC src/sensor.cpp)

# 2. Attach the include directory to the library (PUBLIC means anyone who links this library gets the headers too)
target_include_directories(sensor_lib PUBLIC include/)

# 3. Build the main executable (Notice we removed sensor.cpp!)
add_executable(firmware src/main.cpp)

# 4. Link the library to the executable
target_link_libraries(firmware PRIVATE sensor_lib)
</pre>

=== 2. Rebuild and Verify ===
Go into your <code>build/</code> directory and just run <code>make</code> (CMake automatically detects the changes to CMakeLists.txt and regenerates everything).

<pre>
cd build
make
</pre>

Look at the terminal output. You should see it building <code>libsensor_lib.a</code> first, and then linking it to <code>firmware</code>. Run <code>ls -l</code> to verify the <code>.a</code> archive exists.

---

== Part 4: Remote 3rd-Party Dependencies (30 Minutes) ==
Our IoT node generates data, but we need to format it as JSON to send it over the network. Writing a JSON parser in C++ from scratch is a terrible idea. We will use a popular 3rd-party library (Nlohmann JSON) and import it directly from GitHub using CMake's <code>FetchContent</code>.

=== 1. Fetching the Library ===
Open your <code>CMakeLists.txt</code> and add the FetchContent block ''before'' your executable definition:

<pre>
cmake_minimum_required(VERSION 3.14) # Note: Upgraded to 3.14 for FetchContent
project(IoTNode CXX)

set(CMAKE_CXX_STANDARD 14)

# --- Define local library ---
add_library(sensor_lib STATIC src/sensor.cpp)
target_include_directories(sensor_lib PUBLIC include/)

# --- Fetch 3rd Party Library from GitHub ---
include(FetchContent)
FetchContent_Declare(
json
GIT_REPOSITORY https://github.com/nlohmann/json.git
GIT_TAG v3.11.2
)
FetchContent_MakeAvailable(json)

# --- Define Executable ---
add_executable(firmware src/main.cpp)

# Link BOTH our local hardware library AND the remote JSON library
# (The remote library exposes a target named 'nlohmann_json::nlohmann_json')
target_link_libraries(firmware PRIVATE sensor_lib nlohmann_json::nlohmann_json)
</pre>

=== 2. Use the JSON Library in Code ===
Open <code>src/main.cpp</code> and update it to serialize our sensor data:

<pre>
#include <iostream>
#include "../include/sensor.h"
#include <nlohmann/json.hpp> // Included from the fetched library!

using json = nlohmann::json;

int main() {
std::cout << "Starting IoT Node..." << std::endl;
init_sensor();

SensorData current_data = read_sensor();

// Create a JSON object and pack our data into it
json payload;
payload["device_id"] = "RPI_NODE_01";
payload["status"] = "active";
payload["data"]["temperature"] = current_data.temperature;
payload["data"]["humidity"] = current_data.humidity;

// Serialize and print the JSON string
std::string network_message = payload.dump(4); // 4 spaces of indentation
std::cout << "\n--- Transmission Payload ---\n" << network_message << std::endl;

return 0;
}
</pre>

=== 3. The Final Build ===
Go to your <code>build/</code> directory. Run <code>make</code>.
''Note: This build will take slightly longer because CMake is reaching out to GitHub, downloading the library, and configuring it on the fly.''

Run <code>./firmware</code>. You should see a perfectly formatted JSON payload printed to your terminal!

---

== Lab Deliverable ==
To receive full credit for this week's lab, demonstrate the following to your professor or TA:
# Run <code>./firmware</code> to show the successful JSON serialization.
# Show your <code>CMakeLists.txt</code> file demonstrating the <code>FetchContent</code> block and <code>target_link_libraries</code>.
# Navigate to <code>build/_deps/json-src</code> in your terminal to prove that CMake successfully downloaded the external repository into the out-of-source build tree.
# Explain the difference between the <code>PUBLIC</code> and <code>PRIVATE</code> keywords in your CMake link step.

Software Development Process and Testing

2026-03-15T22:37:25Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]
* [[SDPT Lab 3]]

SDPT Lab 2

2026-03-02T14:11:50Z

Rhobincu:

= Lab 2: Multi-Player Git, Code Reviews, and Advanced Conflict Resolution =

== Introduction ==
In Week 1, you learned how to drive Git in "single-player mode." Today, we switch to "multi-player mode." Software engineering is a team sport. When multiple engineers edit the same codebase simultaneously, collisions are inevitable, and uninterrupted work is a myth.

By the end of this 2-hour lab, you and your partner will have:
# Configured a shared team repository with strict Branch Protection.
# Used <code>git stash</code> to handle an emergency "hotfix" interruption.
# Conducted an iterative Code Review (requesting and pushing fixes).
# Intentionally caused a Git Merge Conflict.
# Resolved the conflict professionally using <code>git rebase</code> and force-pushing.

'''Requirement:''' Find a partner. Decide who will be '''Student A (The Maintainer)''' and who will be '''Student B (The Developer)'''.

---

== Part 1: Team Setup and Branch Protection (20 Minutes) ==
We must first create a shared workspace and establish our "Traffic Laws."

=== 1. Create the Shared Repository (Student A) ===
* '''Student A:''' Log into GitLab and create a new blank project named <code>sdpt-lab2-collaboration</code>.
* Uncheck "Initialize repository with a README".
* On the left sidebar, go to '''Manage''' -> '''Members'''.
* Click '''Invite members'''. Search for '''Student B''' by their university email.
* Assign Student B the role of '''Developer''' and click Invite.

=== 2. Enforce Branch Protection (Student A) ===
The <code>main</code> branch is sacred. No one should be allowed to push code directly to it.
* '''Student A:''' In the project sidebar, go to '''Settings''' -> '''Repository'''.
* Expand the '''Protected branches''' section.
* Ensure the branch is set to <code>main</code> (or <code>master</code>).
* Set '''Allowed to merge''' to: <code>Developers + Maintainers</code>.
* Set '''Allowed to push and merge''' to: <code>No one</code>.
* Click '''Protect'''.

=== 3. Initialize the Baseline (Student A) ===
Student A will push the initial skeleton code.
<syntaxhighlight lang="bash">
mkdir sdpt-lab2-collaboration
cd sdpt-lab2-collaboration
git init
</syntaxhighlight>

Create <code>main.cpp</code>:
<syntaxhighlight lang="cpp">
#include <iostream>

void init_hardware() {
// TODO: Initialize communication protocol
}

int main() {
std::cout << "Sytem Booting..." << std::endl; // Notice the typo!
init_hardware();
return 0;
}
</syntaxhighlight>

Commit and push:
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Initial baseline code"
git remote add origin git@gitlab.com:<Student-A-Username>/sdpt-lab2-collaboration.git
git push -u origin main
</syntaxhighlight>

=== 4. Clone the Repository (Student B) ===
* '''Student B:''' Copy the SSH clone URL from GitLab.
* Clone the repository to your machine:
<syntaxhighlight lang="bash">
git clone git@gitlab.com:<Student-A-Username>/sdpt-lab2-collaboration.git
cd sdpt-lab2-collaboration
</syntaxhighlight>

---

== Part 2: The Emergency Interruption & Stash (20 Minutes) ==
Student B is going to start working on a feature, but Student A (acting as the manager) will interrupt them with an urgent bug fix.

=== 1. Start Feature Work (Student B) ===
* '''Student B:''' Create a branch for the I2C driver.
<syntaxhighlight lang="bash">
git checkout -b feature-i2c
</syntaxhighlight>
Open <code>main.cpp</code> and replace the TODO comment:
<syntaxhighlight lang="cpp">
void init_hardware() {
std::cout << "Initializing I2C Bus on Port B..." << std::endl;
}
</syntaxhighlight>
''Wait! Do not commit yet!''

=== 2. The Emergency (Student A) ===
* '''Student A:''' "Stop what you are doing! There is a typo in the main boot message ('Sytem Booting'). We need a hotfix immediately!"

=== 3. The Stash (Student B) ===
Student B cannot switch to the <code>main</code> branch because they have uncommitted I2C changes. They must stash them.
<syntaxhighlight lang="bash">
git stash
git checkout main
git checkout -b hotfix-typo
</syntaxhighlight>

=== 4. Fix the Bug (Student B) ===
Open <code>main.cpp</code> and fix the typo to say <code>"System Booting..."</code>.
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Fix typo in boot message"
git push -u origin hotfix-typo
</syntaxhighlight>
* '''Student B:''' Go to GitLab, open a Merge Request for the hotfix, and assign Student A.
* '''Student A:''' Review the MR, Approve it, and click '''Merge'''.

=== 5. Resume Work (Student B) ===
Student B, now that the emergency is handled, return to your feature and pop your stash.
<syntaxhighlight lang="bash">
git checkout feature-i2c
git stash pop
</syntaxhighlight>
Your I2C code has returned! Commit and push it.
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Add I2C hardware initialization"
git push -u origin feature-i2c
</syntaxhighlight>
Open a Merge Request for <code>feature-i2c</code>.

---

== Part 3: Parallel Dev & Iterative Code Review (25 Minutes) ==
While Student B was working, Student A was supposed to be writing the SPI driver.

=== 1. Create the Collision (Student A) ===
* '''Student A:''' Make sure you are on <code>main</code> and pull the latest changes (the typo fix).
<syntaxhighlight lang="bash">
git checkout main
git pull origin main
git checkout -b feature-spi
</syntaxhighlight>
Open <code>main.cpp</code> and edit the EXACT SAME LINE that Student B edited:
<syntaxhighlight lang="cpp">
void init_hardware() {
std::cout << "Initializing SPI Bus on Port A..." << std::endl;
}
</syntaxhighlight>
Commit, push, and open an MR.
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Add SPI hardware initialization"
git push -u origin feature-spi
</syntaxhighlight>

=== 2. The Iterative Review ===
* '''Student A:''' Go to Student B's Merge Request (the I2C one).
* Do '''NOT''' approve it. We are going to request a change.
* Go to the '''Changes''' tab. Click the comment bubble next to the I2C line and write: ''"We need to specify the baud rate here. Please add 'at 400kHz' to the output."'' Click '''Start a review''' and then '''Submit review'''.

=== 3. Implementing the Fix (Student B) ===
* '''Student B:''' You received a change request. Update your code locally.
<syntaxhighlight lang="cpp">
void init_hardware() {
std::cout << "Initializing I2C Bus on Port B at 400kHz..." << std::endl;
}
</syntaxhighlight>
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Update I2C init to include baud rate per code review"
git push origin feature-i2c
</syntaxhighlight>
* Notice that your GitLab MR automatically updates!
* '''Student A:''' Check the MR again. The requested change is there. Click '''Approve''' and '''Merge'''.

---

== Part 4: The Rebase Conflict (25 Minutes) ==
Because Student B's MR was merged first, Student A's MR (SPI) is now broken.

=== 1. Discovering the Conflict (Student A) ===
* '''Student A:''' Check your <code>feature-spi</code> Merge Request on GitLab. You will see a red warning: '''Merge blocked: merge conflicts must be resolved.'''

=== 2. Fetch and Rebase (Student A) ===
We will resolve this using the professional Trunk-Based standard: Rebasing.
<syntaxhighlight lang="bash">
# Download the latest state of the remote server
git fetch origin

# Replay your SPI commits on top of the newly updated main branch
git rebase origin/main
</syntaxhighlight>
Git will stop and output: <code>CONFLICT (content): Merge conflict in main.cpp.</code>

=== 3. Fix the Code (Student A) ===
Open <code>main.cpp</code>. You will see the Git markers.
<syntaxhighlight lang="cpp">
void init_hardware() {
<<<<<<< HEAD
std::cout << "Initializing I2C Bus on Port B at 400kHz..." << std::endl;
=======
std::cout << "Initializing SPI Bus on Port A..." << std::endl;
>>>>>>> Add SPI hardware initialization
}
</syntaxhighlight>
Delete the markers and combine the code so BOTH interfaces initialize:
<syntaxhighlight lang="cpp">
void init_hardware() {
std::cout << "Initializing I2C Bus on Port B at 400kHz..." << std::endl;
std::cout << "Initializing SPI Bus on Port A..." << std::endl;
}
</syntaxhighlight>

=== 4. Continue and Force Push (Student A) ===
Stage the resolved file and tell the rebase to continue.
<syntaxhighlight lang="bash">
git add main.cpp
git rebase --continue
</syntaxhighlight>
Because rebasing rewrites history, your local branch and the remote branch have diverged. A normal <code>git push</code> will fail. You must force it.
<syntaxhighlight lang="bash">
git push --force origin feature-spi
</syntaxhighlight>

=== 5. Final Approval (Student B) ===
* '''Student B:''' Go to Student A's MR. The conflict is gone!
* Review the code, click '''Approve''', and click '''Merge'''.

---

== Lab Deliverable ==
To receive full credit for this week's lab, call the professor or TA over and demonstrate:
# Your GitLab MR history showing '''three''' merged requests (Hotfix, I2C, SPI).
# Inside the I2C MR, show the comment thread where a change was requested and resolved.
# Run <code>git log --graph --oneline</code> on your terminal to prove the final history includes all features without broken code.

SDPT Lab 2

2026-03-02T14:04:49Z

Rhobincu: Pagină nouă: = Lab 2: Multi-Player Git, Merge Requests, and Conflict Resolution = == Introduction == In Week 1, you learned how to drive Git in "single-player mode." You initialized a reposito...

= Lab 2: Multi-Player Git, Merge Requests, and Conflict Resolution =

== Introduction ==
In Week 1, you learned how to drive Git in "single-player mode." You initialized a repository, staged files, and pushed to your own remote server.

Today, we switch to "multi-player mode." Software engineering is a team sport. When multiple engineers edit the same codebase simultaneously, collisions are inevitable. By the end of this 2-hour lab, you and a partner will have:
# Configured a shared team repository.
# Enforced Trunk-Based Development by locking down the <code>main</code> branch.
# Worked in parallel on feature branches.
# Intentionally caused a Git Merge Conflict.
# Resolved the conflict using Git commands and GitLab Merge Requests (MRs).
# Conducted a formal Code Review.

'''Requirement:''' Find a partner. Decide who will be '''Student A (The Maintainer)''' and who will be '''Student B (The Developer)'''.

---

== Part 1: Team Setup and Branch Protection (20 Minutes) ==
We must first create a shared workspace and establish our "Traffic Laws" (Branch Protection).

=== 1. Create the Shared Repository (Student A) ===
* '''Student A:''' Log into GitLab and create a new blank project named <code>sdpt-lab2-collaboration</code>.
* Uncheck "Initialize repository with a README".
* On the left sidebar, go to '''Manage''' -> '''Members'''.
* Click '''Invite members'''. Search for '''Student B''' by their university email or username.
* Assign Student B the role of '''Developer''' and click Invite.

=== 2. Enforce Branch Protection (Student A) ===
We are using Trunk-Based Development. The <code>main</code> branch is sacred. No one should be allowed to push broken code directly to it.
* '''Student A:''' In the project sidebar, go to '''Settings''' -> '''Repository'''.
* Expand the '''Protected branches''' section.
* Ensure the branch is set to <code>main</code> (or <code>master</code>).
* Set '''Allowed to merge''' to: <code>Developers + Maintainers</code>.
* Set '''Allowed to push and merge''' to: <code>No one</code>.
* Click '''Protect'''.
''(Now, the ONLY way code gets into main is through a Merge Request!)''

=== 3. Initialize the Baseline (Student A) ===
Student A will push the initial skeleton code so you both have a starting point.
<syntaxhighlight lang="bash">
# Student A's Terminal:
mkdir sdpt-lab2-collaboration
cd sdpt-lab2-collaboration
git init
</syntaxhighlight>

Create a file named <code>main.cpp</code>:
<syntaxhighlight lang="cpp">
#include <iostream>

void init_hardware() {
// TODO: Initialize communication protocol
}

int main() {
std::cout << "System Booting..." << std::endl;
init_hardware();
return 0;
}
</syntaxhighlight>

Commit and push:
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Initial baseline code"
git remote add origin git@gitlab.com:<Student-A-Username>/sdpt-lab2-collaboration.git
git push -u origin main
</syntaxhighlight>

=== 4. Clone the Repository (Student B) ===
* '''Student B:''' Go to Student A's GitLab project page. Copy the SSH clone URL.
* Open your terminal and clone the shared repository to your machine:
<syntaxhighlight lang="bash">
git clone git@gitlab.com:<Student-A-Username>/sdpt-lab2-collaboration.git
cd sdpt-lab2-collaboration
</syntaxhighlight>

---

== Part 2: Parallel Realities (30 Minutes) ==
Both students will now create isolated branches and attempt to implement the hardware initialization logic at the exact same time.

=== 1. Branching Out (Both Students) ===
Both students must run the following commands on their own machines:
<syntaxhighlight lang="bash">
# Student A runs:
git checkout -b feature-spi-init

# Student B runs:
git checkout -b feature-i2c-init
</syntaxhighlight>

=== 2. Writing the Code (Both Students) ===
Open <code>main.cpp</code> in your text editor. Find the <code>init_hardware()</code> function.

'''Student A (SPI Logic):''' Replace the TODO comment with this exact code:
<syntaxhighlight lang="cpp">
void init_hardware() {
std::cout << "Initializing SPI Bus on Port A..." << std::endl;
}
</syntaxhighlight>

'''Student B (I2C Logic):''' Replace the TODO comment with this exact code:
<syntaxhighlight lang="cpp">
void init_hardware() {
std::cout << "Initializing I2C Bus on Port B..." << std::endl;
}
</syntaxhighlight>

=== 3. Commit and Push (Both Students) ===
Because you are on separate branches, you can both push to the server safely.
<syntaxhighlight lang="bash">
# Student A:
git add main.cpp
git commit -m "Add SPI hardware initialization"
git push -u origin feature-spi-init

# Student B:
git add main.cpp
git commit -m "Add I2C hardware initialization"
git push -u origin feature-i2c-init
</syntaxhighlight>

=== 4. Open Merge Requests (Both Students) ===
* Both students: Go to the GitLab project page.
* You should see a blue banner saying "You pushed to feature-...". Click '''Create merge request'''.
* Assign your partner as the '''Reviewer'''.
* Click '''Create merge request'''.

---

== Part 3: The Collision & Code Review (30 Minutes) ==
Right now, both Merge Requests look green and ready to merge. Git doesn't know there is a problem yet.

=== 1. Review and Merge Student A's Code ===
* '''Student B:''' Go to the Merge Requests tab and click on Student A's MR (SPI init).
* Go to the '''Changes''' tab to review the code.
* Leave a comment on the line of code: "Looks good, SPI is the correct protocol."
* Click '''Approve''', then click the green '''Merge''' button.

Student A's code is now officially part of the <code>main</code> branch!

=== 2. The Conflict Appears ===
* '''Student B:''' Go back to the Merge Requests list and open your own MR (I2C init).
* You will see a glaring error: '''Merge blocked: merge conflicts must be resolved.'''
* ''Why did this happen?'' Both of you edited the exact same line in <code>main.cpp</code>. Git refuses to guess whether the SPI code or the I2C code should win. A human must intervene.

---

== Part 4: Resolving the Conflict (30 Minutes) ==
Student B must pull the new changes from the server and fix the conflict locally before they can merge.

=== 1. Update the Local Main Branch (Student B) ===
Student B, your local machine does not know about Student A's merged code yet.
<syntaxhighlight lang="bash">
# Switch back to main
git checkout main

# Download the latest changes from the server
git pull origin main
</syntaxhighlight>

=== 2. Rebase or Merge? (Student B) ===
Switch back to your feature branch. We need to integrate the new <code>main</code> into your feature branch. We will use a merge to resolve the conflict.
<syntaxhighlight lang="bash">
git checkout feature-i2c-init
git merge main
</syntaxhighlight>

Git will output: <code>CONFLICT (content): Merge conflict in main.cpp. Automatic merge failed.</code>

=== 3. Fix the Code (Student B) ===
Open <code>main.cpp</code> in your text editor. Git has injected markers into your code:

<syntaxhighlight lang="cpp">
void init_hardware() {
<<<<<<< HEAD
std::cout << "Initializing I2C Bus on Port B..." << std::endl;
=======
std::cout << "Initializing SPI Bus on Port A..." << std::endl;
>>>>>>> main
}
</syntaxhighlight>

* '''Task:''' Discuss with Student A. Decide that you actually need ''both'' protocols to initialize.
* Delete the Git markers (<code><<<<<<<</code>, <code>=======</code>, <code>>>>>>>></code>) and combine the logic so it looks like this:

<syntaxhighlight lang="cpp">
void init_hardware() {
std::cout << "Initializing SPI Bus on Port A..." << std::endl;
std::cout << "Initializing I2C Bus on Port B..." << std::endl;
}
</syntaxhighlight>

=== 4. Finalize the Merge (Student B) ===
Now that the conflict is manually fixed, tell Git it is resolved:
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Resolve merge conflict between SPI and I2C initialization"
git push origin feature-i2c-init
</syntaxhighlight>

=== 5. Final Approval (Student A) ===
* '''Student A:''' Go to Student B's Merge Request on GitLab.
* Notice the conflict warning is gone. The MR is green again!
* Review the Changes to ensure both SPI and I2C are initialized.
* Click '''Approve''', then click '''Merge'''.

---

== Lab Deliverable ==
To receive full credit for this week's lab, both partners must call the professor or teaching assistant over to your workstation and demonstrate:
# The shared GitLab repository showing the <code>main</code> branch with both SPI and I2C logic combined.
# The '''Settings -> Repository -> Protected branches''' screen showing that <code>main</code> cannot be pushed to directly.
# The '''Merge Requests''' tab showing two Closed/Merged MRs with review comments visible.
# Run <code>git log --graph --oneline</code> on your terminal to show the visual graph of the diverging branches and the merge commit.

Software Development Process and Testing

2026-03-02T13:42:59Z

Rhobincu:

* [[SDPT Lab 1]]
* [[SDPT Lab 2]]

Main Page

2026-03-02T13:42:39Z

Rhobincu: /* Laboratories List */

The purpose of this page is the index the lab tutorials and tasks, as well as the auxiliary resources for the lectures and laboratories taught within the DCAE department.

== Course List ==

* [[Integrated Digital Circuits (lecture)]]
* [[Data Structures and Algorithms]]
* [[Power Semiconductor Devices]]

== Laboratories List ==
* [[Advanced Digital Systems]]
* [[Data Structures and Algorithms (lab)]]
* [[Digital Integrated Circuits (lab)|Digital Integrated Circuits]]
* [[Digital Integrated Circuits (old lab)|Digital Integrated Circuits - old]]
* [[Object Oriented Programming]]
* [[Power Semiconductor Devices (lab)]]
* [https://users.dcae.pub.ro/~zhascsi/courses/dsd/dsd.html Digital Systems Design Project]
* [[Electronic Devices(lab)]]
* [[Electronic Circuits(lab)]]
* [[Software Development Process and Testing]]

== Seminaries List ==
* [[Digital Integrated Circuits (sem)|Digital Integrated Circuits]]

== Applications List ==
* [[Digital Integrated Circuits (app)|Digital Integrated Circuits]]

== Project List ==
* [[Project 1 - Electronic Devices and Circuits |Electronic Devices and Circuits (Project 1)]]

* [[Project Master |Project Master]]

== Evaluation Forms ==
* [[Evaluation Forms 2014-2015, Semester I]]
* [[Evaluation Forms 2014-2015, Semester II]]

Software Development Process and Testing

2026-03-02T13:42:03Z

Rhobincu: Rhobincu a redenumit pagina Software Development Process and Resting în Software Development Process and Testing fără a lăsa o redirecționare în loc

* [[SDPT Lab 1]]

SDPT Lab 1

2026-02-23T00:41:41Z

Rhobincu: /* Part 1: Secure Authentication (SSH Keys) */

= Lab 1: Foundation of Process - Git and GitLab Basics =

== Introduction ==
Welcome to the first lab of Software Development Process and Testing (SDPT). In our lecture, we discussed why treating software like a physical breadboard leads to failure in complex systems. We introduced the Software Development Life Cycle (SDLC), Issue Tracking, and the underlying graph model of Git.

Today, we put theory into practice. By the end of this 2-hour lab, you will have:
# Configured secure SSH authentication with your GitLab server.
# Created a project repository and your first tracked Issue.
# Configured Git on your local machine.
# Moved a C++ source file through the Three States of Git.
# Prevented binary files from entering your repository using <code>.gitignore</code>.
# Pushed your local history to the remote GitLab server to automatically close your Issue.

'''Note:''' Do not rush. The goal is to understand ''where'' your files are in the Git graph at any given moment. Run <code>git status</code> frequently!

== Part 1: Secure Authentication (SSH Keys) ==
Modern code repositories do not allow you to push code using your standard web password. We must set up a secure cryptographic key pair.

=== 1. Generate an SSH Key Pair ===
Open your terminal (Linux/macOS) or Git Bash (Windows) and type:
<syntaxhighlight lang="bash">
ssh-keygen -t ed25519 -C "your.university.email@stud.####.upb.ro"
</syntaxhighlight>
* Press '''Enter''' to accept the default file location.
* Press '''Enter''' twice to skip creating a passphrase (for the sake of this lab environment).

This generated two files: a private key (never share this!) and a public key.

=== 2. Add the Public Key to GitLab ===
Display your public key in the terminal and copy the output exactly:
<syntaxhighlight lang="bash">
cat ~/.ssh/id_ed25519.pub
</syntaxhighlight>
* Log into your university GitLab account in your browser.
* Click your profile avatar (top right) -> '''Edit profile''' -> '''SSH Keys''' (on the left sidebar).
* Click '''Add new key'''. Paste your copied key into the "Key" box. Title it "My Lab Laptop" and click '''Add key'''.

== Part 2: Setting Up the Remote (GitLab) ==
Before we write code, we document our work.

=== 1. Create a New Repository ===
* Go to the GitLab homepage. Click '''New Project''' -> '''Create blank project'''.
* '''Project Name:''' <code>sdpt-rfid-access</code>
* '''Visibility Level:''' Private (or Internal).
* '''Important:''' Uncheck "Initialize repository with a README". We want an entirely empty repository.
* Click '''Create project'''.

=== 2. Create Your First Issue ===
* On the left sidebar of your new project, navigate to '''Plan''' -> '''Issues'''.
* Click '''New issue'''.
* '''Title:''' <code>Create initial RFID reader driver skeleton</code>
* '''Description:''' <code>Need a basic main.cpp file that will eventually hold the SPI communication logic for the RFID module.</code>
* Click '''Create issue'''. Take note of the '''Issue Number''' (e.g., <code>#1</code>).

== Part 3: Initializing the Local Environment ==
=== 1. Configure Your Identity ===
Git embeds your name and email into every commit permanently. Run these once:
<syntaxhighlight lang="bash">
git config --global user.name "Your First and Last Name"
git config --global user.email "your.university.email@domain.edu"
</syntaxhighlight>

=== 2. Create Your Local Workspace ===
Create a folder for your project and initialize it as a Git repository.
<syntaxhighlight lang="bash">
mkdir sdpt-rfid-access
cd sdpt-rfid-access
git init
</syntaxhighlight>

== Part 4: Ignoring the Noise (.gitignore) ==
In C/C++, compiling creates binary files (like <code>.o</code>, <code>.out</code>, or <code>.exe</code>). We '''never''' track compiled binaries in Git—we only track human-readable source code!

Let's tell Git to permanently ignore build files.
Create a file named exactly <code>.gitignore</code>:
<syntaxhighlight lang="bash">
touch .gitignore
</syntaxhighlight>

Open it in your editor and add these lines:
<syntaxhighlight lang="text">
# Ignore compiled binaries
*.o
*.out
*.exe
# Ignore IDE folders
.vscode/
.idea/
</syntaxhighlight>

Save the file. Let's stage and commit our configuration:
<syntaxhighlight lang="bash">
git add .gitignore
git commit -m "Add .gitignore for C++ project"
</syntaxhighlight>

== Part 5: The Three States in Practice ==
Let's move our actual source code through the Working Directory, Staging Area, and Repository.

=== 1. The Working Directory ===
Create your C++ file:
<syntaxhighlight lang="bash">
touch main.cpp
</syntaxhighlight>

Open <code>main.cpp</code> and add a basic skeleton:
<syntaxhighlight lang="cpp">
#include <iostream>

int main() {
std::cout << "RFID Access Control System Initialized" << std::endl;
return 0;
}
</syntaxhighlight>

Check your radar:
<syntaxhighlight lang="bash">
git status
</syntaxhighlight>
''Notice <code>main.cpp</code> is red. It is Untracked.''

=== 2. The Staging Area (Index) ===
Tell Git to include this in the next snapshot.
<syntaxhighlight lang="bash">
git add main.cpp
git status
</syntaxhighlight>
''It is now green. It is Staged.''

=== 3. Time Travel and Diffs ===
Wait! Before committing, what exactly did we just stage? It's good practice to review your code.
<syntaxhighlight lang="bash">
git diff --staged
</syntaxhighlight>
This shows you the exact lines of C++ you are about to commit. Press <code>q</code> to exit the diff view if it pauses.

=== 4. The Repository (Commit) ===
Save the snapshot permanently.
<syntaxhighlight lang="bash">
git commit -m "Add initial RFID system skeleton"
git status
</syntaxhighlight>

== Part 6: Connecting Local to Remote and Closing Issues ==
Your code is safe locally, but the "Bus Factor" is still 1. We must push to GitLab using the SSH key we created earlier.

=== 1. Link the Remote Server ===
Go back to your GitLab project page. Under "Push an existing Git repository", click the '''SSH''' button (not HTTPS) and copy the <code>git remote add origin...</code> command. It will look like this:
<syntaxhighlight lang="bash">
git remote add origin git@gitlab.com:your-username/sdpt-rfid-access.git
</syntaxhighlight>
Paste and run that in your terminal.

=== 2. Push and Close the Issue ===
Let's make one final change to fulfill our Issue requirement and close it automatically.
Open <code>main.cpp</code> and add a comment:
<syntaxhighlight lang="cpp">
// TODO: Implement SPI communication with RC522 module
</syntaxhighlight>

Stage and commit this change, using the special keyword (<code>Closes #1</code>) in your commit message:
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Add SPI TODO comment. Closes #1"
</syntaxhighlight>

Push your local graph to the remote server:
<syntaxhighlight lang="bash">
git push -u origin main
</syntaxhighlight>
''(Note: If Git complains about 'main', try <code>git push -u origin master</code>, or ask your professor how to rename your default branch).''

When prompted "Are you sure you want to continue connecting?", type <code>yes</code> and press Enter.

=== 3. Verify the Magic ===
Refresh your GitLab project page in your browser:
* Your <code>main.cpp</code> and <code>.gitignore</code> files are visible!
* Go to '''Plan''' -> '''Issues'''. Notice that Issue #1 is now automatically marked as '''Closed'''.

== Lab Deliverable ==
To receive full credit for this week's lab, call the professor or teaching assistant over to your workstation and demonstrate:
# Your GitLab repository showing the code and the <code>.gitignore</code> file.
# Your GitLab Issue board showing Issue #1 as Closed.
# Your terminal showing the output of the <code>git log --oneline</code> command, displaying your three commits.

SDPT Lab 1

2026-02-23T00:40:39Z

Rhobincu:

= Lab 1: Foundation of Process - Git and GitLab Basics =

== Introduction ==
Welcome to the first lab of Software Development Process and Testing (SDPT). In our lecture, we discussed why treating software like a physical breadboard leads to failure in complex systems. We introduced the Software Development Life Cycle (SDLC), Issue Tracking, and the underlying graph model of Git.

Today, we put theory into practice. By the end of this 2-hour lab, you will have:
# Configured secure SSH authentication with your GitLab server.
# Created a project repository and your first tracked Issue.
# Configured Git on your local machine.
# Moved a C++ source file through the Three States of Git.
# Prevented binary files from entering your repository using <code>.gitignore</code>.
# Pushed your local history to the remote GitLab server to automatically close your Issue.

'''Note:''' Do not rush. The goal is to understand ''where'' your files are in the Git graph at any given moment. Run <code>git status</code> frequently!

== Part 1: Secure Authentication (SSH Keys) ==
Modern code repositories do not allow you to push code using your standard web password. We must set up a secure cryptographic key pair.

=== 1. Generate an SSH Key Pair ===
Open your terminal (Linux/macOS) or Git Bash (Windows) and type:
<syntaxhighlight lang="bash">
ssh-keygen -t ed25519 -C "your.university.email@domain.edu"
</syntaxhighlight>
* Press '''Enter''' to accept the default file location.
* Press '''Enter''' twice to skip creating a passphrase (for the sake of this lab environment).

This generated two files: a private key (never share this!) and a public key.

=== 2. Add the Public Key to GitLab ===
Display your public key in the terminal and copy the output exactly:
<syntaxhighlight lang="bash">
cat ~/.ssh/id_ed25519.pub
</syntaxhighlight>
* Log into your university GitLab account in your browser.
* Click your profile avatar (top right) -> '''Edit profile''' -> '''SSH Keys''' (on the left sidebar).
* Click '''Add new key'''. Paste your copied key into the "Key" box. Title it "My Lab Laptop" and click '''Add key'''.

== Part 2: Setting Up the Remote (GitLab) ==
Before we write code, we document our work.

=== 1. Create a New Repository ===
* Go to the GitLab homepage. Click '''New Project''' -> '''Create blank project'''.
* '''Project Name:''' <code>sdpt-rfid-access</code>
* '''Visibility Level:''' Private (or Internal).
* '''Important:''' Uncheck "Initialize repository with a README". We want an entirely empty repository.
* Click '''Create project'''.

=== 2. Create Your First Issue ===
* On the left sidebar of your new project, navigate to '''Plan''' -> '''Issues'''.
* Click '''New issue'''.
* '''Title:''' <code>Create initial RFID reader driver skeleton</code>
* '''Description:''' <code>Need a basic main.cpp file that will eventually hold the SPI communication logic for the RFID module.</code>
* Click '''Create issue'''. Take note of the '''Issue Number''' (e.g., <code>#1</code>).

== Part 3: Initializing the Local Environment ==
=== 1. Configure Your Identity ===
Git embeds your name and email into every commit permanently. Run these once:
<syntaxhighlight lang="bash">
git config --global user.name "Your First and Last Name"
git config --global user.email "your.university.email@domain.edu"
</syntaxhighlight>

=== 2. Create Your Local Workspace ===
Create a folder for your project and initialize it as a Git repository.
<syntaxhighlight lang="bash">
mkdir sdpt-rfid-access
cd sdpt-rfid-access
git init
</syntaxhighlight>

== Part 4: Ignoring the Noise (.gitignore) ==
In C/C++, compiling creates binary files (like <code>.o</code>, <code>.out</code>, or <code>.exe</code>). We '''never''' track compiled binaries in Git—we only track human-readable source code!

Let's tell Git to permanently ignore build files.
Create a file named exactly <code>.gitignore</code>:
<syntaxhighlight lang="bash">
touch .gitignore
</syntaxhighlight>

Open it in your editor and add these lines:
<syntaxhighlight lang="text">
# Ignore compiled binaries
*.o
*.out
*.exe
# Ignore IDE folders
.vscode/
.idea/
</syntaxhighlight>

Save the file. Let's stage and commit our configuration:
<syntaxhighlight lang="bash">
git add .gitignore
git commit -m "Add .gitignore for C++ project"
</syntaxhighlight>

== Part 5: The Three States in Practice ==
Let's move our actual source code through the Working Directory, Staging Area, and Repository.

=== 1. The Working Directory ===
Create your C++ file:
<syntaxhighlight lang="bash">
touch main.cpp
</syntaxhighlight>

Open <code>main.cpp</code> and add a basic skeleton:
<syntaxhighlight lang="cpp">
#include <iostream>

int main() {
std::cout << "RFID Access Control System Initialized" << std::endl;
return 0;
}
</syntaxhighlight>

Check your radar:
<syntaxhighlight lang="bash">
git status
</syntaxhighlight>
''Notice <code>main.cpp</code> is red. It is Untracked.''

=== 2. The Staging Area (Index) ===
Tell Git to include this in the next snapshot.
<syntaxhighlight lang="bash">
git add main.cpp
git status
</syntaxhighlight>
''It is now green. It is Staged.''

=== 3. Time Travel and Diffs ===
Wait! Before committing, what exactly did we just stage? It's good practice to review your code.
<syntaxhighlight lang="bash">
git diff --staged
</syntaxhighlight>
This shows you the exact lines of C++ you are about to commit. Press <code>q</code> to exit the diff view if it pauses.

=== 4. The Repository (Commit) ===
Save the snapshot permanently.
<syntaxhighlight lang="bash">
git commit -m "Add initial RFID system skeleton"
git status
</syntaxhighlight>

== Part 6: Connecting Local to Remote and Closing Issues ==
Your code is safe locally, but the "Bus Factor" is still 1. We must push to GitLab using the SSH key we created earlier.

=== 1. Link the Remote Server ===
Go back to your GitLab project page. Under "Push an existing Git repository", click the '''SSH''' button (not HTTPS) and copy the <code>git remote add origin...</code> command. It will look like this:
<syntaxhighlight lang="bash">
git remote add origin git@gitlab.com:your-username/sdpt-rfid-access.git
</syntaxhighlight>
Paste and run that in your terminal.

=== 2. Push and Close the Issue ===
Let's make one final change to fulfill our Issue requirement and close it automatically.
Open <code>main.cpp</code> and add a comment:
<syntaxhighlight lang="cpp">
// TODO: Implement SPI communication with RC522 module
</syntaxhighlight>

Stage and commit this change, using the special keyword (<code>Closes #1</code>) in your commit message:
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Add SPI TODO comment. Closes #1"
</syntaxhighlight>

Push your local graph to the remote server:
<syntaxhighlight lang="bash">
git push -u origin main
</syntaxhighlight>
''(Note: If Git complains about 'main', try <code>git push -u origin master</code>, or ask your professor how to rename your default branch).''

When prompted "Are you sure you want to continue connecting?", type <code>yes</code> and press Enter.

=== 3. Verify the Magic ===
Refresh your GitLab project page in your browser:
* Your <code>main.cpp</code> and <code>.gitignore</code> files are visible!
* Go to '''Plan''' -> '''Issues'''. Notice that Issue #1 is now automatically marked as '''Closed'''.

== Lab Deliverable ==
To receive full credit for this week's lab, call the professor or teaching assistant over to your workstation and demonstrate:
# Your GitLab repository showing the code and the <code>.gitignore</code> file.
# Your GitLab Issue board showing Issue #1 as Closed.
# Your terminal showing the output of the <code>git log --oneline</code> command, displaying your three commits.

SDPT Lab 1

2026-02-23T00:39:55Z

Rhobincu:

= Lab 1: Foundation of Process - Git and GitLab Basics =

== Introduction ==
Welcome to the first lab of Software Development Process and Testing (SDPT). In our lecture, we discussed why treating software like a physical breadboard leads to failure in complex systems. We introduced the Software Development Life Cycle (SDLC), Issue Tracking, and the underlying graph model of Git.

Today, we put theory into practice. By the end of this 2-hour lab, you will have:
# Configured secure SSH authentication with your GitLab server.
# Created a project repository and your first tracked Issue.
# Configured Git on your local machine.
# Moved a C++ source file through the Three States of Git.
# Prevented binary files from entering your repository using <code>.gitignore</code>.
# Pushed your local history to the remote GitLab server to automatically close your Issue.

'''Note:''' Do not rush. The goal is to understand ''where'' your files are in the Git graph at any given moment. Run <code>git status</code> frequently!

== Part 1: Secure Authentication (SSH Keys) ==
Modern code repositories do not allow you to push code using your standard web password. We must set up a secure cryptographic key pair.

=== 1. Generate an SSH Key Pair ===
Open your terminal (Linux/macOS) or Git Bash (Windows) and type:
<syntaxhighlight lang="bash">
ssh-keygen -t ed25519 -C "your.university.email@domain.edu"
</syntaxhighlight>
* Press '''Enter''' to accept the default file location.
* Press '''Enter''' twice to skip creating a passphrase (for the sake of this lab environment).

This generated two files: a private key (never share this!) and a public key.

=== 2. Add the Public Key to GitLab ===
Display your public key in the terminal and copy the output exactly:
<syntaxhighlight lang="bash">
cat ~/.ssh/id_ed25519.pub
</syntaxhighlight>
* Log into your university GitLab account in your browser.
* Click your profile avatar (top right) -> '''Edit profile''' -> '''SSH Keys''' (on the left sidebar).
* Click '''Add new key'''. Paste your copied key into the "Key" box. Title it "My Lab Laptop" and click '''Add key'''.

== Part 2: Setting Up the Remote (GitLab) ==
Before we write code, we document our work.

=== 1. Create a New Repository ===
* Go to the GitLab homepage. Click '''New Project''' -> '''Create blank project'''.
* '''Project Name:''' <code>sdpt-rfid-access</code>
* '''Visibility Level:''' Private (or Internal).
* '''Important:''' Uncheck "Initialize repository with a README". We want an entirely empty repository.
* Click '''Create project'''.

=== 2. Create Your First Issue ===
* On the left sidebar of your new project, navigate to '''Plan''' -> '''Issues'''.
* Click '''New issue'''.
* '''Title:''' <code>Create initial RFID reader driver skeleton</code>
* '''Description:''' <code>Need a basic main.cpp file that will eventually hold the SPI communication logic for the RFID module.</code>
* Click '''Create issue'''. Take note of the '''Issue Number''' (e.g., <code>#1</code>).

== Part 3: Initializing the Local Environment ==
=== 1. Configure Your Identity ===
Git embeds your name and email into every commit permanently. Run these once:
<syntaxhighlight lang="bash">
git config --global user.name "Your First and Last Name"
git config --global user.email "your.university.email@domain.edu"
</syntaxhighlight>

=== 2. Create Your Local Workspace ===
Create a folder for your project and initialize it as a Git repository.
<syntaxhighlight lang="bash">
mkdir sdpt-rfid-access
cd sdpt-rfid-access
git init
</syntaxhighlight>

== Part 4: Ignoring the Noise (.gitignore) ==
In C/C++, compiling creates binary files (like <code>.o</code>, <code>.out</code>, or <code>.exe</code>). We '''never''' track compiled binaries in Git—we only track human-readable source code!

Let's tell Git to permanently ignore build files.
Create a file named exactly <code>.gitignore</code>:
<syntaxhighlight lang="bash">
touch .gitignore
</syntaxhighlight>

Open it in your editor and add these lines:
<syntaxhighlight lang="text">
# Ignore compiled binaries
*.o
*.out
*.exe
# Ignore IDE folders
.vscode/
.idea/
</syntaxhighlight>

Save the file. Let's stage and commit our configuration:
<syntaxhighlight lang="bash">
git add .gitignore
git commit -m "Add .gitignore for C++ project"
</syntaxhighlight>

== Part 5: The Three States in Practice ==
Let's move our actual source code through the Working Directory, Staging Area, and Repository.

=== 1. The Working Directory ===
Create your C++ file:
<syntaxhighlight lang="bash">
touch main.cpp
</syntaxhighlight>

Open <code>main.cpp</code> and add a basic skeleton:
<syntaxhighlight lang="cpp">
#include <iostream>

int main() {
std::cout << "RFID Access Control System Initialized" << std::endl;
return 0;
}
</syntaxhighlight>

Check your radar:
<syntaxhighlight lang="bash">
git status
</syntaxhighlight>
''Notice <code>main.cpp</code> is red. It is Untracked.''

=== 2. The Staging Area (Index) ===
Tell Git to include this in the next snapshot.
<syntaxhighlight lang="bash">
git add main.cpp
git status
</syntaxhighlight>
''It is now green. It is Staged.''

=== 3. Time Travel and Diffs ===
Wait! Before committing, what exactly did we just stage? It's good practice to review your code.
<syntaxhighlight lang="bash">
git diff --staged
</syntaxhighlight>
This shows you the exact lines of C++ you are about to commit. Press <code>q</code> to exit the diff view if it pauses.

=== 4. The Repository (Commit) ===
Save the snapshot permanently.
<syntaxhighlight lang="bash">
git commit -m "Add initial RFID system skeleton"
git status
</syntaxhighlight>

---

== Part 6: Connecting Local to Remote and Closing Issues ==
Your code is safe locally, but the "Bus Factor" is still 1. We must push to GitLab using the SSH key we created earlier.

=== 1. Link the Remote Server ===
Go back to your GitLab project page. Under "Push an existing Git repository", click the '''SSH''' button (not HTTPS) and copy the <code>git remote add origin...</code> command. It will look like this:
<syntaxhighlight lang="bash">
git remote add origin git@gitlab.com:your-username/sdpt-rfid-access.git
</syntaxhighlight>
Paste and run that in your terminal.

=== 2. Push and Close the Issue ===
Let's make one final change to fulfill our Issue requirement and close it automatically.
Open <code>main.cpp</code> and add a comment:
<syntaxhighlight lang="cpp">
// TODO: Implement SPI communication with RC522 module
</syntaxhighlight>

Stage and commit this change, using the special keyword (<code>Closes #1</code>) in your commit message:
<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Add SPI TODO comment. Closes #1"
</syntaxhighlight>

Push your local graph to the remote server:
<syntaxhighlight lang="bash">
git push -u origin main
</syntaxhighlight>
''(Note: If Git complains about 'main', try <code>git push -u origin master</code>, or ask your professor how to rename your default branch).''

When prompted "Are you sure you want to continue connecting?", type <code>yes</code> and press Enter.

=== 3. Verify the Magic ===
Refresh your GitLab project page in your browser:
* Your <code>main.cpp</code> and <code>.gitignore</code> files are visible!
* Go to '''Plan''' -> '''Issues'''. Notice that Issue #1 is now automatically marked as '''Closed'''.

---

== Lab Deliverable ==
To receive full credit for this week's lab, call the professor or teaching assistant over to your workstation and demonstrate:
# Your GitLab repository showing the code and the <code>.gitignore</code> file.
# Your GitLab Issue board showing Issue #1 as Closed.
# Your terminal showing the output of the <code>git log --oneline</code> command, displaying your three commits.

SDPT Lab 1

2026-02-23T00:34:29Z

Rhobincu: Pagină nouă: = Lab 1: Foundation of Process - Git and GitLab Basics = == Introduction == Welcome to the first lab of Software Development Process and Testing (SDPT). In our lecture, we discuss...

= Lab 1: Foundation of Process - Git and GitLab Basics =

== Introduction ==
Welcome to the first lab of Software Development Process and Testing (SDPT). In our lecture, we discussed why treating software like a physical breadboard leads to failure in complex systems. We introduced the Software Development Life Cycle (SDLC), Issue Tracking, and the underlying graph model of Git.

Today, we put theory into practice. By the end of this 2-hour lab, you will have:
# Created a project repository on GitLab.
# Created your first tracked Issue.
# Configured Git on your local machine.
# Moved a C++ source file through the Three States of Git.
# Pushed your local history to the remote GitLab server and automatically closed your Issue.

'''Note:''' Do not rush. The goal is to understand ''where'' your files are in the Git graph at any given moment. Run <code>git status</code> frequently!

---

== Part 1: Setting Up the Remote (GitLab) ==
Before we touch the terminal, we need to set up our remote infrastructure and document the work we intend to do.

=== 1. Create a New Repository ===
* Log into your university GitLab account.
* Click '''New Project''' -> '''Create blank project'''.
* '''Project Name:''' <code>sdpt-rfid-access</code>
* '''Visibility Level:''' Private (or Internal, depending on your professor's instructions).
* '''Important:''' Uncheck "Initialize repository with a README". We want an entirely empty repository to practice pushing from our local machine.
* Click '''Create project'''.

=== 2. Create Your First Issue ===
We need a business requirement before we write code.
* On the left sidebar of your new project, navigate to '''Plan''' -> '''Issues'''.
* Click '''New issue'''.
* '''Title:''' <code>Create initial RFID reader driver skeleton</code>
* '''Description:''' <code>Need a basic main.cpp file that will eventually hold the SPI communication logic for the RFID module.</code>
* Click '''Create issue'''.
* Take note of the '''Issue Number''' (e.g., <code>#1</code>) generated next to the title. You will need this later!

---

== Part 2: Initializing the Local Environment ==
Now, open your terminal (Linux/macOS) or Git Bash (Windows).

=== 1. Configure Your Identity ===
Git embeds the author's name and email into every commit permanently. You only need to run these commands once per computer.

<syntaxhighlight lang="bash">
git config --global user.name "Your First and Last Name"
git config --global user.email "your.university.email@domain.edu"
</syntaxhighlight>

=== 2. Create Your Local Workspace ===
Create a folder for your project and initialize it as a Git repository.

<syntaxhighlight lang="bash">
mkdir sdpt-rfid-access
cd sdpt-rfid-access
git init
</syntaxhighlight>

Notice the output: <code>Initialized empty Git repository</code>. A hidden <code>.git</code> folder has been created. This is your database.

---

== Part 3: The Three States in Practice ==
Remember the three states from the lecture: Working Directory, Staging Area, and Repository. Let's move a file through them.

=== 1. The Working Directory ===
Create a new C++ file. This represents writing your initial code.

<syntaxhighlight lang="bash">
touch main.cpp
</syntaxhighlight>

Open <code>main.cpp</code> in your favorite text editor (nano, vim, VS Code) and add a basic skeleton:

<syntaxhighlight lang="cpp">
#include <iostream>

int main() {
std::cout << "RFID Access Control System Initialized" << std::endl;
return 0;
}
</syntaxhighlight>

Now, check your radar:
<syntaxhighlight lang="bash">
git status
</syntaxhighlight>
''Notice that <code>main.cpp</code> is red and listed under "Untracked files". Git sees the file in your Working Directory, but is not managing it yet.''

=== 2. The Staging Area (Index) ===
Tell Git you want to include this file in your next commit snapshot.

<syntaxhighlight lang="bash">
git add main.cpp
git status
</syntaxhighlight>
''Notice the file is now green and under "Changes to be committed". It is in the Staging Area.''

=== 3. The Repository (Commit) ===
Save the snapshot permanently into your local Git database.

<syntaxhighlight lang="bash">
git commit -m "Add initial RFID system skeleton"
git status
</syntaxhighlight>
''Your working tree is now clean. The snapshot is stored as a node in your local Git graph.''

---

== Part 4: Connecting Local to Remote and Closing Issues ==
Your code is safe locally, but the "Bus Factor" is still 1. If your laptop crashes, the code is gone. We must push to GitLab.

=== 1. Link the Remote Server ===
Go back to your GitLab project page. Under "Push an existing Git repository", copy the <code>git remote add origin...</code> command. It will look like this:

<syntaxhighlight lang="bash">
git remote add origin https://gitlab.com/your-username/sdpt-rfid-access.git
</syntaxhighlight>

=== 2. Push and Close the Issue ===
We want to push our code AND tell GitLab that this code fulfills the requirement we documented in Part 1. We do this by making a new commit that references the Issue number.

Let's make a small change to <code>main.cpp</code>. Open it and add a comment:
<syntaxhighlight lang="cpp">
// TODO: Implement SPI communication with RC522 module
</syntaxhighlight>

Now, stage and commit this change, using a special keyword (<code>Closes #1</code>) in the commit message:

<syntaxhighlight lang="bash">
git add main.cpp
git commit -m "Add SPI TODO comment. Closes #1"
</syntaxhighlight>

Finally, push your local graph to the remote server:

<syntaxhighlight lang="bash">
git push -u origin main
</syntaxhighlight>
''(Note: If your default branch is 'master' instead of 'main', use <code>git push -u origin master</code>)''

=== 3. Verify the Magic ===
Go back to your browser and refresh your GitLab project page:
* Your <code>main.cpp</code> file is now visible on the server!
* Go to '''Plan''' -> '''Issues'''. Notice that Issue #1 is now automatically marked as '''Closed'''. Git and GitLab worked together to link your code directly to the business requirement.

---

== Lab Deliverable ==
To receive full credit for this week's lab, call the professor or teaching assistant over to your workstation and demonstrate:
# Your GitLab repository showing the <code>main.cpp</code> file.
# Your GitLab Issue board showing Issue #1 as Closed.
# Your terminal showing the output of the <code>git log</code> command, displaying your two commits.

Software Development Process and Testing

2026-02-23T00:34:18Z

Rhobincu: Pagină nouă: * SDPT Lab 1

* [[SDPT Lab 1]]

Main Page

2026-02-23T00:33:36Z

Rhobincu:

The purpose of this page is the index the lab tutorials and tasks, as well as the auxiliary resources for the lectures and laboratories taught within the DCAE department.

== Course List ==

* [[Integrated Digital Circuits (lecture)]]
* [[Data Structures and Algorithms]]
* [[Power Semiconductor Devices]]

== Laboratories List ==
* [[Advanced Digital Systems]]
* [[Data Structures and Algorithms (lab)]]
* [[Digital Integrated Circuits (lab)|Digital Integrated Circuits]]
* [[Digital Integrated Circuits (old lab)|Digital Integrated Circuits - old]]
* [[Object Oriented Programming]]
* [[Power Semiconductor Devices (lab)]]
* [https://users.dcae.pub.ro/~zhascsi/courses/dsd/dsd.html Digital Systems Design Project]
* [[Electronic Devices(lab)]]
* [[Electronic Circuits(lab)]]
* [[Software Development Process and Resting]]

== Seminaries List ==
* [[Digital Integrated Circuits (sem)|Digital Integrated Circuits]]

== Applications List ==
* [[Digital Integrated Circuits (app)|Digital Integrated Circuits]]

== Project List ==
* [[Project 1 - Electronic Devices and Circuits |Electronic Devices and Circuits (Project 1)]]

* [[Project Master |Project Master]]

== Evaluation Forms ==
* [[Evaluation Forms 2014-2015, Semester I]]
* [[Evaluation Forms 2014-2015, Semester II]]

SDA Lucrarea 1

2024-09-29T18:47:58Z

Rhobincu:

După acest laborator veți putea folosi IDE-ul Netbeans pentru a scrie și depana programe în C. Totodată veți relua și recapitula noțiunile legate de pointeri în C.

= Utilizarea IDE-ului CLion =

[https://www.jetbrains.com/clion CLion] este un mediu integrat de dezvoltare (IDE) care permite dezvoltarea de programe în limbajele C și C++. CLion nu instalează și compilator pentru C/C++, acesta trebuie instalat manual, în prealabil.

<div class="regula"><span style="color: red; font-weight: bold">Atenție:</span> Imaginea de Linux folosită la Programarea Calculatoarelor are deja instalat compilatorul de C.</div>

== Instalarea GCC ==

=== Instalarea GCC în Linux ===

Pentru instalarea compilatorului de C (GCC) în distribuțiile de Linux provenite din Ubuntu (Ubuntu, Kubuntu, Xubuntu, Mint, LMDE, etc.) se poate folosi comanda:

apt-get install -y build-essential

=== Instalarea GCC în Windows ===

Pentru compilarea de programe cu GCC în Windows, aveți nevoie de instalarea acestui compilator care poate fi făcută prin instalarea unuia din următoarele două suite de programe:
* [https://cygwin.com Cygwin] - Tutorial de instalare [https://cygwin.com/install.html aici].
* [http://www.mingw.org/ MinGW] - Tutorial de instalare [http://www.mingw.org/wiki/InstallationHOWTOforMinGW aici].

<div class="regula"><span style="color: red; font-weight: bold">Atenție:</span> Nu uitați ca la instalare să bifați în lista de pachete și compilatorul de C (<code>gcc</code>), <code>make</code> și <code>git</code>.</div>

== Instalarea CLion ==

De la adresa https://www.jetbrains.com/clion/download/#section=linux puteți descărca kitul de instalare pentru sistemul vostru de operare.
După instalare, urmaţi următorii paşi de configurare, în funcţie de suita de programe aleasă:
* [https://www.jetbrains.com/help/clion/quick-tutorial-on-configuring-clion-on-windows.html#Cygwin Configurare CLion cu Cygwin]
* [https://www.jetbrains.com/help/clion/quick-tutorial-on-configuring-clion-on-windows.html#MinGW Configurare CLion cu MinGW]

== Realizarea unui proiect ==

Odată pornit, CLion oferă posibilitatea de a deschide un proiect existent, sau de a crea unul nou. Vrem să realizăm un proiect nou, aşadar se va alege '''New Project'''.

<div class="regula"> ''' Observație: ''' Se poate realiza un nou proiect atunci când altul este deja deschis folosind meniul <code>File - New Project </code> .</div>

[[Fișier:Welcome_to_clion.png | 600px | Imaginea 1]]

<br> Mai departe se va selecta categoria '''C++ Executable''' şi se va introduce locaţia proiectului.

<div class="regula"><span style="color: red; font-weight: bold">Atenție:</span> În imagine se observă că locaţia introdusă este '''/home/student/projects/NewProject'''. Se recomandă ca directorul în care se realizează proiectul să aibă numele proiectului, sau un nume sugestiv (în imagine '''NewProject''')</div>

[[Fișier:New_project_location_clion.png | 600px | Imaginea 2]]

== Componentele IDE-ului CLion ==

[[Fișier:CLion_env.png | 1000px | Imaginea 3]]

La crearea unui nou proiect, IDE-ul CLion generează automat fişierul '''main.cpp'''. Acesta conţine un exemplu program ce va fi rescris de către utilizator. <br>

Secţiunile marcate în imagine reprezintă:
# Zona <span style="color: green">verde</span> - '''Project view''' indică toate fişierele şi directoarele ce alcătuiesc proiectul.
# Zona <span style="color: blue">albastră</span> - '''Editor''' este fereastra de vizualizare şi editare a textului
# Zona <span style="color: red">roşie</span> - '''Toolbar''' oferă acces rapid pentru operaţiile uzuale. Dintre acestea, cel mai des vom folosi:
#*'''Build''' [[Fișier:CLion_build_button.png | 16px]]
#*'''Run''' [[Fișier:CLion_run_button.png | 16px]]
#*'''Debug''' [[Fișier:CLion_debug_button.png | 16px]]
# Zona <span style="color: gold">galbenă</span> - '''Run''' este zona în care se introduc datele de intrare şi se în care vor fi afişate datele de ieşire.

== Exemplu de program în modul ''debug'' ==

Copiați codul de mai jos înlocuind programul deja existent în fișierul ''main.c'':
<syntaxhighlight lang="C" line>
#include <stdio.h>

int main(){
printf("Debugging program...\n");
int value = 0;
value = value + 1;
value++;
value = value * 2;
value -= 1;
printf("Value is now %d!\n", value);
return 0;
}
</syntaxhighlight>

Pentru a executa programul în modul debug trebuie sa introducem cel puţin un '''breakpoint'''. Astfel indicăm programului unde se va opri pentru a ne acorda control asupra execuţiei, având posibilitatea de a continua execuţia pas cu pas. <br>

Introducem un nou breakpoint dând click în dreptul liniei de la care vrem să obţinem controlul. În cazul nostru, vom alege să indroducem un breakpoint chiar la definirea variabilei <code>value</code>.

[[Fișier:CLion_breakpoint.png | 1000px | Imaginea 4]]

<div class="regula"><span style="color: red; font-weight: bold">Atenție:</span> Când alegem locaţia unui breakpoint trebuie să ţinem cont de următorul aspect: în modul '''debug''' programul se va opri '''înainte''' de a executa linia în dreptul căreia a fost introdus breakpoint-ul!</div>

În continuare, trebuie se pornim execuţia programului in modul debug [[Fișier:CLion_debug_button.png | 16px]]. Observăm apariţia ferestrei Debug (chenarul albastru, Imaginea 5) ce conţine următoarele:
#Zona <span style="color: gold">galbenă</span> - fereastra cu toate variabilele declarate, împreună cu valorile lor. Momentan nu există nicio variabilă declarată (deoarece linia asupra la care ne-am oprit nu a fost încă executată!)
#Zona <span style="color: red">roşie</span> - Permite trecerea între fereastra pentru procesul de depanare ('''Debugger''') şi fereastra în care se afişează/introduc datele ('''Console''')
#Zona <span style="color: green">verde</span> - Conţine comenzile pentru controlul execuţiei în modul debug (comenzi numite '''stepping actions'''):
#*'''Step over''' [[Fișier:CLion_step_over.png | 16px]] - Execută comenzile de pe linia curentă şi trece la următoarea linie
#*'''Step into''' [[Fișier:CLion_step_into.png | 16px]] - Programul va executa linia curentă iar dacă pe linia curentă există un apel de funcție, se va opri pe prima linie din funcția respectivă. Această comandă este utilă atunci cand pe linia curentă se află un apel de funcţie şi vrem sa studiem comportamentul codului din interiorul funcţiei.
#*'''Step out''' [[Fișier:CLion_step_out.png | 16px]] - Termină de executat funcţia în care se află linia curentă
#*'''Run to cursor''' [[Fișier:CLion_run_to_cursor.png | 16px]] - Execută toate instructiunile până se intâlneste cursorul.

<div class="regula"> ''' Observație: ''' În modul debug, linia curentă este marcată de către mediul de dezvoltare prin colorarea acesteia cu albastru.</div>

Alte comenzi utile:
*'''Resume program''' [[Fișier:CLion_resume_project.png | 16px]] - Continuă execuţia pâmă la următorul breakpoint (dacă nu există, se va executa până la final)
*'''Stop''' [[Fișier:CLion_stop.png | 16px]] - Se opreşte definitv execuţia programului, împreună cu modul debug

[[Fișier:CLion_debug_process.png | 1000px | Imaginea 5]]<br>

Pentru a exersa utilizarea sistemului de debug, realizați următoarele operații:
# Parcurgeti tot programul folosind '''Step Over''' și vizualizând valoarea variabilei <code>value</code> la fiecare pas, până la ultima linie din program, unde utilizați '''Resume program'''.
# Reporniți aplicația în modul de debug și puneți un al doilea ''breakpoint'' pe linia cu apelul funcției <code>printf</code>.
# Folosiți '''Resume program''' pentru a ajunge la al doilea ''breakpoint''.
# Odată ajunși acolo, folosiți '''Step In''' pentru a intra în funcția <code>printf</code> (neavând codul sursă, veți vedea codul de asamblare obținut din dezasamblarea fișierului obiect de către GDB).
# Folosiți '''Step Out''' pentru a reveni în funcția <code>main</code> și apoi '''Resume program''' pentru a termina execuția.

== Tips & Tricks ==

=== Formatare automată a codului ===

CLion oferă opțiunea de a formata automat codul prin selectarea '''Code -> Reformat Code'''.

Ce probleme rezolvă această formatare automată:
* alinierea liniilor în funcție de blocurile de instrucțiuni și tipurile de ''statements'' de pe fiecare linie;
* plasarea sau eliminarea de spații acolo unde este necasar.
Ce probleme NU rezolvă această formatare automată;
* lipsa acoladelor de la blocurile '''if''' și '''for''';
* numele insuficient de sugestive pentru numele de funcții, structuri sau variabile.

Stilul conform căruia este modificat codul poate fi configurat folosind meniul <code>File|Settings|Editor|CodeStyle</code>

=== Generare automată a codului ===

CLion oferă posibilitatea de a genera fragmente de cod des înâlnite, precum constructori şi operatori în interiorul claselor. Această acţiune poate fi realizată folosind meniul <code> Code|Generate</code>.

=== Altele ===
* [https://www.jetbrains.com/help/clion/using-todo.html TODO Comments]

<br> Nu uitați de regulile următoare: [[Convenții de cod - C]]



= Probleme propuse =

Problemele de mai jos au anumite erori care trebuie gasite si raparate folosind debugger-ul.

== Problema 1 ==
Programul de mai jos ar trebui să citească de la tastatură un șir de maxim 1024 caractere și să afișeze câte litere mici, câte litere mari și câte cifre conține acest șir. Totuși acest program are o eroare. Folosiți debugger-ul pentru a o identifica și repara.

Exemplu de intrare:

Ana a plecat la piata si a cumparat 10 saci de cartofi.

Ieșirea pentru intrarea de mai sus:

40 1 2

<syntaxhighlight lang="C++">
#include <stdio.h>

int main() {
char c;
unsigned uppercaseChars = 0;
unsigned lowecaseChars = 0;
unsigned digits = 0;

while(scanf("%c", c) != EOF) {
if(c > 'a' || c < 'z') {
lowecaseChars++;
} else if(c > 'A' && c < 'Z') {
uppercaseChars++;
} else {
digits++;
}
}
printf("%u %u %u", lowecaseChars, uppercaseChars, digits);
return 0;
}
</syntaxhighlight>

== Problema 2 ==
Un tehnician a măsurat un număr mare n de rezistori şi a obţinut n valori de rezistenţe. Tehnicianul ştie că rezistorii sunt de acelaşi fel, dar pentru că sunt vechi şi codul culorilor nu mai este vizibil, doreşte să calculeze valoarea nominală a rezistenţei (R) şi dispersia valorilor, (S). Apoi, având aceste valori, el vrea să determine câte din rezistenţele testate (procentual) se încadrează în intervalul [R – S; R + S]. Rezistenţa nominală se calculează ca media aritmetică a valorilor rezistenţelor, iar formula dispersiei este dată mai jos.

Cerinţă
Dându-se un număr n de rezistori şi valorile rezistenţelor acestora Ri (i = 1, ..., n), să se determine procentul rezistoarelor care au rezistenţa în intervalul [R– S; R + S].

Date de intrare
Pe prima linie se află numărul întreg n. Pe următoarea linie, separate printr-un spaţiu, sunt n valori fracţionare de rezistenţe (în ohmi).

Date de ieşire
Se va afişa o singură valoare fracţionară, cu exact două zecimale reprezentând procentul de rezistori cu rezistenţa în intervalul [R – S; R + S].

Restricţii şi precizări:

1 < n < 1000

1.0 <= Ri <= 10000.0

S=sqrt( pow(sum(R[i]−R),2) / n )

Exemplu:

Input =
10

76 1 20 37 19 92 61 96 37 77

Output =
50.00

<syntaxhighlight lang="C++">
#include <vector>
#include <string>
#include <unordered_map>
#include <algorithm>
#include <cstdio>

int main() {
int n;
double values[n];
scanf("%d", &n);
int sum = 0;
for(int i = 0; i < n; i++){
scanf("%lf", &values[i]);
sum += values[i];
}
double average = sum / n;
double dispersion = 0;
for(int i = 0; i < n; i++){
dispersion += (values[i] - average) * (values[i] - average);
}
dispersion = sqrt(dispersion / n);
int larger = 0;
for(int i = 0; i < n; i++) {
if(values[i] >= average - dispersion
&& values[i] <= average + dispersion) larger++;
}
printf("%.2lf", 100 * larger / n);
return 0;
}
</syntaxhighlight>

== Problema 3 ==
Sunteți angajați de ministerul învățamântului să scrieți un program care să listeze toți elevii care au promovat examenul de bacalaureat. De la tastatură se introduce un număr n reprezentând numărul de candidați, apoi pe următoarele n linii, un nume de elev (format din exact două cuvinte: nume și prenume) și notele la cele patru materii, format fracționar, valori între 1 și 10. Să se afișeze toți studenții care au promovat examenul de bacalaureat (media mai mare ca 6, fiecare notă mai mare ca 5) în ordinea inversă a introducerii lor, împreună cu media de promovare, afișată cu fix două zecimale.

Exemplu de date de intrare:

4

Gheorghe Ghita 8 7 5.5 10

Vuia Vasile 4 10 10 10

Andreescu Andra 9 10 9 10

Elenescu Elena 5 5 5 5

Ieșirea pentru intrarea de mai sus:

Andreescu Andra 9.50

Gheorghe Ghita 7.63

<syntaxhighlight lang="C++">
#include <stdio.h>
struct studenti{
char n[128];
char m[128];
float a,b,c,d;
};
int main(){
int n,i;
struct studenti s[n];
scanf("%d", &n);
for(i=0;i<n;i++)
scanf("%s%s%f%f%f%f",&s[i].n,&s[i].m,&s[i].a,&s[i].b,&s[i].c,&s[i].d);

for(i=n;i>0;i--){
float m=(s[i].a+s[i].b+s[i].c+s[i].d)/4;
if(s[i].a>5&&s[i].b>5&&s[i].c>5&&s[i].d>5||m>=6){
printf("%s %s %.2f\n",s[i].n,s[i].m,m);
}
}
return 0;
}
</syntaxhighlight>

Colocviu pclp1

2024-09-07T12:01:51Z

Rhobincu:

= Cerință =

Sunteți la ora de matematică și tocmai ați învățat despre vectori și matrici. Pentru că întotdeauna v-au pasionat calculatoarele, ați reușit să învățați informatica de bază de timpuriu și, de asemenea, să asimilați cunoștințe despre matrici și vectori prin intermediul ei. Vi s-a dat o temă la matematică și, pentru a vă ușura munca, ați decis să scrieți un program care să rezolve cerințele din temă.

Tema este următoarea:

Aveți un șir de numere întregi. Pentru acest șir vi se cer următoarele:

# ''(6p)'' Pentru fiecare trei numere consecutive din șir calculați media lor aritmetică și afișați mediile, separate cu câte un spațiu între ele. Pentru ușurință se va afișa un spațiu și după ultima medie. Acestea vor fi afișate ca numere fracționare, cu două zecimale după virgulă.
# ''(6p)'' Pentru mediile calculate anterior, găsiți maximul dintre ele și afișați-l, tot cu 2 zecimale după virgulă.
# ''(6p)'' Cu numerele pozitive (mai mari strict ca 0) și pare, vi se cere să formați un nou șir de numere și să calculați mediile aritmetice, de data aceasta pentru câte două numere. Numerele folosite pentru medii vor fi: primul cu ultimul, al doilea cu penultimul și tot așa. Dacă numărul de numere din noul șir este impar, numărul din mijloc va reprezenta el singur una dintre medii. Afișați maximul dintre aceste medii nou obținute, de asemenea cu 2 zecimale după virgulă.
# ''(6p)'' Pentru șirul de numere inițiale, vi se cere să formați cea mai mare matrice pătratică care se poate realiza cu numerele din șir și să o afișați. Numerele vor fi separate pe fiecare linie cu câte un spațiu și, pentru ușurință, se va afișa un spațiu și după ultimul element de pe o linie. Toate liniile se vor termina cu un caracter newline.
# ''(6p)'' La acest subpunct vi se garantează că matricea pătratică obținută conține doar numere de o cifră. Voi trebuie să formați câte un număr pentru fiecare coloană din matrice. Numerele se formează prin alipirea respectivelor cifre, începând cu cea de pe prima linie și terminând cu cifra de pe ultima linie. Dintre numerele astfel obținute, afisați doar numerele prime, cu câte un spațiu între ele. Pentru ușurință, se va afișa un spațiu și după ultimul număr.

Datele de intrare vor fi, pentru fiecare subpunct, de forma:

numar_elemente
elementele din sir separate cu un spatiu
litera_subpunct

unde pentru subpunctul 1, litera_subpunct este a, pentru 2: b, ș.a.m.d.

= Exemple =

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
a

== Ieșire ==

8.00 8.33 4.67 7.00 4.67 3.67 1.00 2.33

== Explicații ==

Media primelor trei numere este (7 + 15 + 2) / 3 = 8.00, a următoarelor trei numere: (15 + 2 + 8) / 3 = 8.33 etc.

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
b

== Ieșire ==

8.33

== Explicații ==

Mediile sunt: 8.00, 8.33, 4.67, 7.00, 4.67, 3.67, 1.00, respectiv 2.33, maximul dintre ele fiind 8.33.

== Intrare ==

16
7 15 -2 8 2 -4 9 1 1 1 5 4 6 6 -8 3
c

== Ieșire ==

7.00

== Explicații ==

Șirul nou format din numerele pare și pozitive este: 8, 2, 4, 6, 6. Mediile vor fi: (8 + 6) / 2 = 7, (2 + 6) / 2 = 4 și 4 (doarece numărul numerelor este impar). Cea mai mare valoare dintre acestea trei este 7.00.

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
d

== Ieșire ==

7 15 2
8 4 9
1 1 1

== Explicații ==

Avem 10 numere în șir, deci cea mai mare matrice pătratică va fi formată din primele 9 numere deoarece 9 este cel mai apropiat pătrat perfect mai mic decât 10.

== Intrare ==

10
1 2 3 3 5 6 7 8 7 1
e

== Ieșire ==

137 367

== Explicații ==

Matricea formată va fi:

1 2 3
3 5 6
7 8 7

Numerele rezultate prin alipirea cifrelor de pe fiecare coloană vor fi 137, 258 și 367, dintre care 137 și 367 sunt numere prime și ele vor fi afișate.

Colocviu pclp1

2024-09-07T12:01:25Z

Rhobincu:

= Cerință =

Sunteți la ora de matematică și tocmai ați învățat despre vectori și matrici. Pentru că întotdeauna v-au pasionat calculatoarele, ați reușit să învățați informatica de bază de timpuriu și, de asemenea, să asimilați cunoștințe despre matrici și vectori prin intermediul ei. Vi s-a dat o temă la matematică și, pentru a vă ușura munca, ați decis să scrieți un program care să rezolve cerințele din temă.

Tema este următoarea:

Aveți un șir de numere întregi. Pentru acest șir vi se cer următoarele:

# ''(6p)'' Pentru fiecare trei numere consecutive din șir calculați media lor aritmetică și afișați mediile, separate cu câte un spațiu între ele. Pentru ușurință se va afișa un spațiu și după ultima medie. Acestea vor fi afișate ca numere fracționare, cu două zecimale după virgulă.
# ''(6p)'' Pentru mediile calculate anterior, găsiți maximul dintre ele și afișați-l, tot cu 2 zecimale după virgulă.
# ''(6p)'' Cu numerele pozitive (mai mari strict ca 0) și pare, vi se cere să formați un nou șir de numere și să calculați mediile aritmetice, de data aceasta pentru câte două numere. Numerele folosite pentru medii vor fi: primul cu ultimul, al doilea cu penultimul și tot așa. Dacă numărul de numere din noul șir este impar, numărul din mijloc va reprezenta el singur una dintre medii. Afișați maximul dintre aceste medii nou obținute, de asemenea cu 2 zecimale după virgulă.
# ''(6p)'' Pentru șirul de numere inițiale, vi se cere să formați cea mai mare matrice pătratică care se poate realiza cu numerele din șir și să o afișați. Numerele vor fi separate pe fiecare linie cu câte un spațiu și, pentru ușurință, se va afișa un spațiu și după ultimul element de pe o linie. Toate liniile se vor termina cu un caracter newline.
# ''(6p)'' La acest subpunct vi se garantează că matricea pătratică obținută conține doar numere de o cifră. Voi trebuie să formați câte un număr pentru fiecare coloană din matrice. Numerele se formează prin alipirea respectivelor cifre, începând cu cea de pe prima linie și terminând cu cifra de pe ultima linie. Dintre numerele astfel obținute, afisați doar numerele prime, cu câte un spațiu între ele. Pentru ușurință, se va afișa un spațiu și după ultimul număr.

Datele de intrare vor fi, pentru fiecare subpunct, de forma:

numar_elemente
elementele din sir separate cu un spatiu
litera_subpunct

unde pentru subpunctul 1, litera_subpunct este a, pentru 2: b, ș.a.m.d.

= Exemple =

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
a

== Ieșire ==

8.00 8.33 4.67 7.00 4.67 3.67 1.00 2.33

== Explicații

Media primelor trei numere este (7 + 15 + 2) / 3 = 8.00, a următoarelor trei numere: (15 + 2 + 8) / 3 = 8.33 etc.

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
b

== Ieșire ==

8.33

== Explicații ==

Mediile sunt: 8.00, 8.33, 4.67, 7.00, 4.67, 3.67, 1.00, respectiv 2.33, maximul dintre ele fiind 8.33.

== Intrare ==

16
7 15 -2 8 2 -4 9 1 1 1 5 4 6 6 -8 3
c

== Ieșire ==

7.00

== Explicații ==

Șirul nou format din numerele pare și pozitive este: 8, 2, 4, 6, 6. Mediile vor fi: (8 + 6) / 2 = 7, (2 + 6) / 2 = 4 și 4 (doarece numărul numerelor este impar). Cea mai mare valoare dintre acestea trei este 7.00.

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
d

== Ieșire ==

7 15 2
8 4 9
1 1 1

== Explicații ==

Avem 10 numere în șir, deci cea mai mare matrice pătratică va fi formată din primele 9 numere deoarece 9 este cel mai apropiat pătrat perfect mai mic decât 10.

== Intrare ==

10
1 2 3 3 5 6 7 8 7 1
e

== Ieșire ==

137 367

== Explicații ==

Matricea formată va fi:

1 2 3
3 5 6
7 8 7

Numerele rezultate prin alipirea cifrelor de pe fiecare coloană vor fi 137, 258 și 367, dintre care 137 și 367 sunt numere prime și ele vor fi afișate.

Colocviu pclp1

2024-09-07T11:58:48Z

Rhobincu: Pagină nouă: Sunteți la ora de matematică și tocmai ați învățat despre vectori și matrici. Pentru că întotdeauna v-au pasionat calculatoarele, ați reușit să învățați info...

Sunteți la ora de matematică și tocmai ați învățat despre vectori și matrici. Pentru că întotdeauna v-au pasionat calculatoarele, ați reușit să învățați informatica de bază de timpuriu și, de asemenea, să asimilați cunoștințe despre matrici și vectori prin intermediul ei. Vi s-a dat o temă la matematică și, pentru a vă ușura munca, ați decis să scrieți un program care să rezolve cerințele din temă.

Tema este următoarea:

Aveți un șir de numere întregi. Pentru acest șir vi se cer următoarele:

# ''(6p)'' Pentru fiecare trei numere consecutive din șir calculați media lor aritmetică și afișați mediile, separate cu câte un spațiu între ele. Pentru ușurință se va afișa un spațiu și după ultima medie. Acestea vor fi afișate ca numere fracționare, cu două zecimale după virgulă.
# ''(6p)'' Pentru mediile calculate anterior, găsiți maximul dintre ele și afișați-l, tot cu 2 zecimale după virgulă.
# ''(6p)'' Cu numerele pozitive (mai mari strict ca 0) și pare, vi se cere să formați un nou șir de numere și să calculați mediile aritmetice, de data aceasta pentru câte două numere. Numerele folosite pentru medii vor fi: primul cu ultimul, al doilea cu penultimul și tot așa. Dacă numărul de numere din noul șir este impar, numărul din mijloc va reprezenta el singur una dintre medii. Afișați maximul dintre aceste medii nou obținute, de asemenea cu 2 zecimale după virgulă.
# ''(6p)'' Pentru șirul de numere inițiale, vi se cere să formați cea mai mare matrice pătratică care se poate realiza cu numerele din șir și să o afișați. Numerele vor fi separate pe fiecare linie cu câte un spațiu și, pentru ușurință, se va afișa un spațiu și după ultimul element de pe o linie. Toate liniile se vor termina cu un caracter newline.
# ''(6p)'' La acest subpunct vi se garantează că matricea pătratică obținută conține doar numere de o cifră. Voi trebuie să formați câte un număr pentru fiecare coloană din matrice. Numerele se formează prin alipirea respectivelor cifre, începând cu cea de pe prima linie și terminând cu cifra de pe ultima linie. Dintre numerele astfel obținute, afisați doar numerele prime, cu câte un spațiu între ele. Pentru ușurință, se va afișa un spațiu și după ultimul număr.

Datele de intrare vor fi, pentru fiecare subpunct, de forma:

numar_elemente
elementele din sir separate cu un spatiu
litera_subpunct

unde pentru subpunctul 1, litera_subpunct este a, pentru 2: b, ș.a.m.d.

= Exemple =

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
a

== Ieșire ==

8.00 8.33 4.67 7.00 4.67 3.67 1.00 2.33

== Explicații

Media primelor trei numere este (7 + 15 + 2) / 3 = 8.00, a următoarelor trei numere: (15 + 2 + 8) / 3 = 8.33 etc.

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
b

== Ieșire ==

8.33

== Explicații

Mediile sunt: 8.00, 8.33, 4.67, 7.00, 4.67, 3.67, 1.00, respectiv 2.33, maximul dintre ele fiind 8.33.

== Intrare ==

16
7 15 -2 8 2 -4 9 1 1 1 5 4 6 6 -8 3
c

== Ieșire ==

7.00

== Explicații

Șirul nou format din numerele pare și pozitive este: 8, 2, 4, 6, 6. Mediile vor fi: (8 + 6) / 2 = 7, (2 + 6) / 2 = 4 și 4 (doarece numărul numerelor este impar). Cea mai mare valoare dintre acestea trei este 7.00.

== Intrare ==

10
7 15 2 8 4 9 1 1 1 5
d

== Ieșire ==

7 15 2
8 4 9
1 1 1

== Explicații

Avem 10 numere în șir, deci cea mai mare matrice pătratică va fi formată din primele 9 numere deoarece 9 este cel mai apropiat pătrat perfect mai mic decât 10.

== Intrare ==

10
1 2 3 3 5 6 7 8 7 1
e

== Ieșire ==

137 367

== Explicații

Matricea formată va fi:

1 2 3
3 5 6
7 8 7

Numerele rezultate prin alipirea cifrelor de pe fiecare coloană vor fi 137, 258 și 367, dintre care 137 și 367 sunt numere prime și ele vor fi afișate.

PC Laborator 8

2023-01-29T09:36:27Z

Rhobincu: /* Căutarea unui caracter într-un șir de caractere */

== Obiective ==

în urma acestui laborator, studentul va fi capabil să:
*înțeleagă cum funcționează șirurile de caractere
*facă operații cu șiruri de caractere

== Șiruri de caractere ==

[[Fișier:ascii_table.jpg|thumb]]

În C, tipul de dată șir nu există în mod implicit. Singurul mod prin care putem opera cu șiruri este folosind tablourile unidimensionale, vectorii. Ne amintim că un vector este definit complet prin intermediul a trei caracteristici: tipul de date conținute, numele vectorului și numărul său de elemente. Așadar, putem declara un vector al cărui tip de data să fie char, caz în care acel vector va fi denumit șir (de caractere).
Declararea unui șir de caractere se face astfel:
<syntaxhighlight lang="C">
char numele_sirului [numarul_de_caractere];
</syntaxhighlight>
<div class="regula"> ''' Observație: ''' Spre deosebire de vectorii studiați în laboratorul anterior, ale căror elemente sunt precizate explicit, șirurile au un caracter special, implicit, numit end of string și reprezentat astfel: \0.
</div>

== Operații cu șiruri ==

Toate proprietățile vectorilor, studiate în laboratorul anterior, sunt valabile și în cazul șirurilor. De asemenea, toate operațiile pe care le putem face cu vectori sunt posibile și în cazul șirurilor.

<div class="regula"> ''' Observație: ''' Există anumite operații asociate exclusiv șirurilor, precum căutarea unor caractere sau a unui șir într-un alt șir, concatenarea, etc. Toate aceste operații au funcții predefinite, care pot fi găsite într-un header specific, string.h. </div>

=== Aflarea lungimii unui șir de caractere ===
Pe lângă metoda clasică, discutată în capitolul anterior, ce presupune parcurgerea șirului și numărarea elementelor acestuia, avem și o metodă proprie șirurilor. Ea presupune apelarea funcției strlen(), predefinita în biblioteca string.h, care va întoarce numărul de elemente al șirului.
<div class="regula"> ''' Observație: ''' Caracterul '\0' marchează sfârșitul șirului, iar acolo se oprește numărarea.
</div>
Sintaxa generala:
<syntaxhighlight lang="C">
lungime_sir = strlen (sir_de_caractere);
</syntaxhighlight>

=== Citirea unui șir de caractere ===
Există mai multe variante pentru a citi un șir de caractere, unele asemănătoare vectorilor, altele specifice șirurilor de caractere.

1. Citirea șirului caracter cu caracter, până la întâlnirea caracterului cu codul ASCII 10 (newline - \n), moment în care se scrie caracterul de sfârșit de șir (null terminator - \0):
<syntaxhighlight lang="C">
char sir_de_caractere[MAX_SIZE];
int i;
for (i = 0; i < MAX_SIZE; i++) {
scanf ("%c", &sir_de_caractere[i]);
/* 10 este codul ascii pentru \n, adica enter */
if (sir_de_caractere[i] == 10) {
sir_de_caractere[i] = '\0';
break;
}
}
</syntaxhighlight>

2. Se folosește <code>scanf</code> cu template-ul <code>%s</code> (atenție, acest <code>scanf</code> va citi exclusiv până la primul caracter alb - spațiu, tab sau newline):
<syntaxhighlight lang="C">
char sir_de_caractere[MAX_SIZE];
scanf ("%s", sir_de_caractere);
</syntaxhighlight>

3. Se folosește <code>scanf</code> cu template-ul <code>%[^\n]</code> (atenție, acest <code>scanf</code> va citi exclusiv până la primul newline pe care nu îl va consuma din stream - acesta va trebui eliminat manual cu apel de <code>getchar()</code>):
<syntaxhighlight lang="C">
char sir_de_caractere[MAX_SIZE];
scanf ("%[^\n]", sir_de_caractere);
getchar();
</syntaxhighlight>

4. Se folosește <code>fgets</code> (atenție, acestă funcție va citi maxim MAX_SIZE - 1 caractere de la tastatură, sau până la întâlnirea lui \n, în care situație caracterul \n va fi adăugat în șir):
<syntaxhighlight lang="C">
char sir_de_caractere[MAX_SIZE];
fgets(sir_de_caractere, MAX_SIZE, stdin);
</syntaxhighlight>

=== Afișarea unui șir de caractere ===
Analog citirii unui șir de caractere, afișarea se poate face și ea în mai multe moduri, după cum urmează:

1. Sintaxa generala:
<syntaxhighlight lang="C">
char sir_de_caractere[MAX_SIZE];
scanf("%s",sir_de_caractere); // citire sir de caractere

int i;
for (i = 0; i < MAX_SIZE && sir_de_caractere [i] != '\0'; i++) {
printf ("%c", sir_de_caractere [i]);
}
</syntaxhighlight>

2. Sintaxa generala
<syntaxhighlight lang="C">
printf ("%s", sir_de_caractere);
</syntaxhighlight>
3. Sintaxa generala:
<syntaxhighlight lang="C">
puts(sir_de_caractere);
</syntaxhighlight>

'''Exemplu''': Fie șirul de caractere sir[10]. Citiți următoarea frază folosind toate cele 3 metode, apoi afișați conținutul șirului folosind puts();. Ce observați? Explicați.

=== Căutarea unui caracter într-un șir de caractere ===
Funcția folosită: strchr();
Sintaxa generala:
<syntaxhighlight lang="C">
char sir_de_caractere[MAX_SIZE], char caracterul_cautat;
char * pointer;
pointer = strchr(sir_de_caractere, caracterul_cautat);
int pozitie = pointer - sir_de_caractere;
</syntaxhighlight>
<div class="regula"> ''' Observație: ''' Funcția strchr NU oferă toate pozițiile pe care se află caracterul_căutat, ci doar prima poziție.
*Pentru a afla ultima poziție pe care se află un caracter căutat, se va folosi funcția strrchr(), sintaxa fiind identică.
*Pentru a caută un șir de caractere într-un alt șir de caractere, se va folosi funcția strstr(), sintaxa fiind aceeași.
</div>

=== Copierea unui șir de caractere în altul ===
Funcția folosită: strcpy ();
Sintaxa:
<syntaxhighlight lang="C">
char destinatie[MAX_SIZE1], sursa[MAX_SIZE2];
strcpy(destinatie, sursa);
</syntaxhighlight>
<div class="regula"> ''' Observație: ''' șirul sursă se copiază în șirul destinație. Dacă lungimea șirului destinație este mai mică decât a șirului sursă, atunci copierea se face cu erori. Trebuie deci să punem următoarea condiție:
<syntaxhighlight lang="C">
MAX_SIZE1 >= strlen(sursa);
</syntaxhighlight>
</div>

=== Concatenarea unor șiruri de caractere ===
Funcția folosită: srtcat();
Sintaxa generala:
<syntaxhighlight lang="C">
char destinatie[MAX_SIZE1], sursa[MAX_SIZE2];
strcat(destinatie, sursa);
</syntaxhighlight>
<div class="regula"> ''' Observație: ''' Concatenarea se face adăugând șirul sursă la șirul destinație. Este deci necesar ca șirul sursă să "încăpă" în șirul destinație. Matematic, asta se traduce astfel:
<syntaxhighlight lang="C">
MAX_SIZE1 >= strlen(sursa) + strlen(destinatie);
</syntaxhighlight>
</div>

=== Compararea a doua șiruri de caractere ===
Funcția folosită: strcmp();
Sintaxa generala:
<syntaxhighlight lang="C">
char sir1 [MAX_SIZE1], sir2 [MAX_SIZE2];
int rezultat;
rezultat = strcmp(sir1, sir2);
</syntaxhighlight>
Funcția strcmp(); întoarce următoarele valori:
* un număr negativ - dacă sir1 este înainte din punct de vedere alfabetic;
* 0 - dacă cele două șiruri sunt identice;
* un număr pozitiv - dacă sir2 este înainte din punct de vedere alfabetic.

=== Inserția unui șir de caractere într-un alt șir ===
Pentru această operație nu există o funcție specializată în biblioteca string.h. Ceea ce vom face va fi să folosim procedee învățate la vectori, cât și funcții menționate anterior. Etapele sunt următoarele:
* declarăm cele două șiruri;
* verificăm dacă șirul ce urmează să fie introdus încape în șirul inițial;
* găsim poziția unde dorim să adăugăm șirul ce urmează să fie introdus;
* începând cu acea poziție, mutăm toate caracterele la dreaptă cu un număr de poziții egal cu lungimea șirului ce urmează să fie introdus;
* pe pozițiile rămase "goale" introducem șirul nou.
'''Exemplu:'''
Transformați fraza "Studentul a picat examenul final." în "Studentul nu a picat examenul final."
Date necesare: sir_inițial[50] = "Sudentul a picat examenul final.", sir_nou[3] = "nu ".

== Observații și exemple==

=== strlen vs sizeof ===

<syntaxhighlight lang="C">
#include <stdio.h>
#include <string.h>
int main()
{
char str1[20] = "StringLab";
int len,size;

len = strlen(str1);
size = sizeof(str1);
printf("Lungimea str1: %d\n", len);
printf("Lungimea total alocata str1: %d\n", size);

return 0;
}

</syntaxhighlight>

=== strchr vs strrchr ===
<syntaxhighlight lang="C">
#include <stdio.h>
#include <string.h>
int main()
{
char str1[40] = "Cautare de caracter printre caractere";
printf ("Caz1: %s\n", strchr(str1, 'a'));
printf ("Caz2: %s\n", strrchr(str1, 'a'));
printf ("Caz3: %s\n", strstr(str1, "de"));

return 0;
}
</syntaxhighlight>

=== Exemple operații cu șiruri===
<syntaxhighlight lang="C">

#include <stdio.h>
#include <string.h>

int main () {

char str1[10] = "Hello";
char str2[10] = "String Lab";
char str3[10];
int len ;

/* copiaza str1 in str3 */
strcpy(str3, str1);
printf("strcpy( str3, str1) : %s\n", str3 );

/* concateneaza str1 str2 */
strcat( str1, str2);
printf("strcat( str1, str2): %s\n", str1 );

/* lungimea str1 dupa concatenare */
len = strlen(str1);
printf("strlen(str1) : %d\n", len );

return 0;
}

</syntaxhighlight>

=== Model de concatenare fără a utiliza strcat ===
<syntaxhighlight lang="C">
#include <stdio.h>
#include <string.h>

int main(){

char str1[10], str2[10], str3[20];
int i, poz;
printf("Introduceti sir1: ");
scanf("%s",str1);
printf("Introduceti sir2: ");
scanf("%s",str2);

for (i = 0; i < strlen(str1); i++)
str3[i] = str1[i];
poz=i;
for (i = 0; i < strlen(str2); i++)
str3[poz+i] = str2[i];
str3[poz+i] ='\0';

printf("Sir concatenat: %s\n",str3);

return 0;
}
</syntaxhighlight>

=== Exemple fgets & puts ===
<syntaxhighlight lang="C">

#include <stdio.h>
#include <string.h>
int main(){
char nume[30];
printf("Numele este: ");
/* Citește string de la utilizator */
fgets(nume, 30, stdin);
printf("Nume: ");
/* Afișează string */
puts(nume);
return 0;
}
</syntaxhighlight>

== Exerciții ==

#Să se scrie un program care citește de la tastatură un cuvânt.Să se afișeze cuvintele ce se obțin prin eliminarea succesiva a primei si ultimei litere din cuvântul citit.
#Să se scrie un program care șterge toate caracterele dintr-o linie citită de la tastatură cu excepția literelor.
#Să se scrie un program care afișează pe ecran frecvența de apariție a unui caracter citit de la tastatură.
#Se citeşte de la tastatură o propoziţie (şir de caractere) terminată cu punct.Să se afişeze fiecare cuvânt din propoziţie pe câte o linie separată.

CID aplicatii 9 : Numaratorul

2022-04-20T17:05:32Z

Rhobincu: /* Exemplul 1: Implementarea unui num[r[tor cu reset sincron */

== Numărătorul ==
Numărătorul este cel mai simplu automat, fiind format dintr-un registru (element de memorare) ce reține valoarea curentă a acestuia și un circuit de incrementare (circuit de reacție) ce generează la ieșirea sa valoarea ce va trebui stocată în registru la următorul front crescător de ceas (valoarea curentă incrementată cu 1).

În figura de mai jos este reprezentat un numărător cu reset sincron:

[[Fișier:Numarator cu reset.png|600px]]

În cazul de mai sus, cât timp semnalul ''reset'' este activ, valoarea numărătorului va fi 0. Atunci când semnalul ''reset'' nu este activ, numărătorul își va incrementa valoarea la fiecare front crescător de ceas.

== Divizor de frecvență cu factor de divizare putere a lui 2==
În unele cazuri, apare necesitatea obținerii unor semnale de ceas cu frecvență mai mică decât cea a ceasului de sistem. Aceste noi semnale de ceas pot fi obținute chiar din semnalul de ceas al sistemului, prin circuite care realizează divizarea acestuia. Cea mai simplă divizare a unui semnal de ceas este cea cu factor de divizare egal cu o putere a lui 2. Pentru acest caz, putem folosi un numărător.

Dacă urmărim figura de mai jos în care sunt reprezentate variațiile fiecărui bit în timpul funcționării unui numărător pe 4 biți, observăm că, cu cât ordinul bitului crește (este mai semnificativ), frecvența de variație este mai mică. Între frecvențele de variație corespunzătoare a doi biți succesivi există următoarea relație: frecvența unui bit este de două ori mai mică decât frecvența bitului anterior (mai puțin semnificativ).

[[Fișier:Divizare frecventa.png]]

Observând că frecvența bitului 0 este de două ori mai mică decât cea a ceasului, putem concluziona că frecvența de variație a bitului cu indicele N este dată de: '''''f<sub>bN</sub>'' = ''f<sub>clk</sub> / 2<sup>N+1</sup>'''''

Așadar, pentru a realiza un divizor de frecvență cu factor de divizare putere a lui 2, putem folosi un numărător îndeajuns de mare, din care extragem bitul cu frecvența de variație egală cu frecvența dorită.

== Exemple==
===Exemplul 1: Implementarea unui numărător cu reset sincron===
În acest exemplu vom realiza implementarea numărătorului cu reset sincron prezentat în figura din secțiunea de introducere teoretică. În plus, vom folosi parametrul WIDTH pentru a controla dimensiunea acestuia.

'''Implementarea Numărătorului cu reset sincron'''
<syntaxhighlight lang="Verilog">
module Numarator
#(parameter WIDTH = 8)
(
input clock,
input reset,
output reg [WIDTH-1:0] count
);

always@(posedge clock) begin
if(reset == 0)
count <= 0;
else
count <= count + 1;
end

endmodule

</syntaxhighlight>

'''Implementarea unui modul de test pentru numărător'''
<syntaxhighlight lang="Verilog">
`timescale 1ns/1ps

module Numarator_TB();

parameter WIDTH_T = 5;
reg reset_t, clock_t;
wire [WIDTH_T-1:0] count_t;

initial begin
clock_t = 0;
forever #1 clock_t = ~clock_t;
end

initial begin
reset_t = 0;
#2 reset_t = 1;
#500 $stop();
end

Numarator #(.WIDTH(WIDTH_T)) DUT(
.clock(clock_t),
.reset(reset_t),
.count(count_t)
);

endmodule

</syntaxhighlight>

'''Observație:''' Cât timp semnalul ''reset'' este inactiv, numărătorul își va incrementa valoarea la fiecare front crescător de ceas. Când va ajunge la valoarea sa maximă (de exemplu, 31 pentru un numărător pe 5 biți), va avea loc o depășire și având la dispozitie un număr limitat de biți (de exemplu, 5), semnalul de ieșire va deveni 0 (reținem doar cei mai puțin semnificativi 5 biți), circuitul reluând numărarea de la capat.

===Exemplul 2: Observarea vitezei de variație a biților unui numărător===
În acest exemplu vom realiza implementarea unui divizor de frecvență ce generează la ieșire 4 semnale de ceas cu următoarele frecvențe:
* ''clkout1'': semnal de ceas cu frecvența de 1 Hz.
* ''clkout2'': semnal de ceas cu frecvența de 2 Hz.
* ''clkout4'': semnal de ceas cu frecvența de 4 Hz.
* ''clkout8'': semnal de ceas cu frecvența de 8 Hz.

Dacă aplicăm formula '''''f<sub>bN</sub>'' = ''f<sub>clk</sub> / 2<sup>N+1</sup>''''' cunoscând că frecvența de ceas a FPGA-ului este de 125 MHz, vom obține:
* ''clkout1'' poate fi obținut prin bitul 26 al unui numărător.
* ''clkout2'' poate fi obținut prin bitul 25 al unui numărător.
* ''clkout4'' poate fi obținut prin bitul 24 al unui numărător.
* ''clkout8'' poate fi obținut prin bitul 23 al unui numărător.

Din rezultatele de mai sus, rezultă că avem nevoie de un numărător pe 27 biți, astfel încât să putem folosi bitul cel mai semnificativ (bitul 26) pentru generarea semnalului de ceas cu frecvența cea mai mică.

'''Implementarea Verilog a circuitului'''
<syntaxhighlight lang="Verilog">
module clock_generator(
input clock,
input reset,
output clkout1,
output clkout2,
output clkout4,
output clkout8,
);

reg [26:0] count;

always@(posedge clock) begin
if(reset == 0)
count <= 0;
else
count <= count + 1;
end

assign clkout1 = count[26];
assign clkout2 = count[25];
assign clkout4 = count[24];
assign clkout8 = count[23];

endmodule

</syntaxhighlight>

'''Implementarea circuitului pe FPGA'''

Realizați sinteza circuitului pe FPGA, ținând cont de următoarele constrângeri de I/O:
{| class="wikitable"
|- align="center"
||'''Port''' || '''Conexiune'''
|- align="center"
| clock || CLK_125MHz
|- align="center"
| reset || Button 0
|- align="center"
| clkout1 || LED3
|- align="center"
| clkout2 || LED2
|- align="center"
| clkout4 || LED1
|- align="center"
| clkout8 || LED0
|}

Observați viteza cu care fiecare din LED-uri se stinge și se aprinde.

== Exerciții==
===Exercițiul 1===
Implementați un numărător parametrizat cu reset sincron și semnal de ''enable''. Semnalul ''enable'' controlează funcționarea numărătorului astfel: când este activ (egal cu 1), permite funcționarea normală (incrementare la fiecare front crescător de ceas); când este inactiv (egal cu 0), va determina numărătorul să își păstreze valoarea curentă.

Implementați și un modul de test care să testeze funcționarea corectă a circuitului.

===Exercițiul 2===
Implementați un numărător parametrizat cu reset sincron și capacitatea de a număra crescător sau descrescător. Controlul direcției de numărare se va realiza cu ajutorul unui semnal ''count_updown'', care controlează funcționarea numărătorului astfel: când este 0, numărătorul va număra crescător, prin incrementarea valorii curente, iar când este 1, numărătorul va număra descrescător, prin decrementarea valorii curente

Implementați și un modul de test care să testeze funcționarea corectă a circuitului.

===Exercițiul 3===
Implementați circuitul descris prin schema de mai jos, știind că:
* COUNTER este un numărător pe 32 biți fără reset.
* RAM este o memorie 16x4b, cu citire sincrona.
* ROM este o memorie 16x4b, ce are descrierea prezentată mai jos.

[[Fișier:Cid_lab6.jpg]]

'''Implementarea modulului ROM'''
<syntaxhighlight lang="Verilog">
module ROM(
input [3:0] in,
output reg [3:0] out
);

always @(in)
case(in)
0: out = 4'b0000;
1: out = 4'b0110;
2: out = 4'b0011;
3: out = 4'b1110;
4: out = 4'b1011;
5: out = 4'b1111;
6: out = 4'b0111;
7: out = 4'b1100;
8: out = 4'b0001;
9: out = 4'b0101;
10: out = 4'b1101;
11: out = 4'b1010;
12: out = 4'b0010;
13: out = 4'b0100;
14: out = 4'b1000;
15: out = 4'b1001;
default: out = 4'b0000;
endcase
endmodule
</syntaxhighlight>

Realizați un modul de test în care să scrieți memoria RAM cu date, astfel încât să se realizeze citirea memoriei ROM în ordine, la fiecare ciclu de ceas (adresa 0 -> adresa 1 -> ... -> adresa 15 -> adresa 0 -> ...)

C++ POO Lab Lucrarea 4

2022-04-12T22:01:59Z

Rhobincu: /* Exemplu */

Această lucrare are ca scop familiarizarea cu următoarele noțiuni:

* Moștenirea
* Ascunderea metodelor
* Polimorfismul
* Metode virtuale și suprascrierea metodelor
* Metode pur virtuale și clase abstracte

= Moștenirea =

== Introducere ==
Moștenirea este mecanismul prin care o clasă preia structura (câmpurile) și comportamentul (metodele) unei alte (sau mai multor) clase, la care poate adăuga alți membri specifici.

Clasa de la care se preiau membrii se numește:
* clasă de bază
* superclasă

Clasa nouă, care preia membrii de la clasa de bază se numește:
* clasă derivată
* clasă extinsă
* subclasă

În C++, moștenirea poate fi multiplă, în sensul că o clasă derivată poate moșteni mai multe clase de bază. Nu în toate limbajele există acest concept (în Java, de exemplu, există doar moștenire simplă - adică o clasă poate moșteni o singură altă clasă).

Utilitatea moștenirii în programarea orientată pe obiecte este:
* reutilizarea codului existent fără modificarea acestuia;
* extinderea a unei clase deja scrise, fără a fi necesară recompilarea ei;
* utilizarea polimorfismului în timpul execuției, prin folosirea metodelor virtuale.

== Exemplu ==
<syntaxhighlight lang="C++" line highlight="29">
#include <string>
#include <cstdio>

class Animal {
std::string mName;
std::string mColor;
int mAge;
protected:
bool mHasFeathers;

public:
void makeSound() const {
printf("Animal %s makes a sound!\n", mName.c_str());
}

// this is a getter method
std::string getName() const {
return mName;
}

// this is a setter method
void setAge(int age) {
if(age > 0) {
mAge = age;
}
}
};

class Cat : public Animal {
unsigned int mLives;
public:
Cat() : mLives(9) {
mHasFeathers = false;
}
};

int main() {
Cat cat;
cat.makeSound(); // makeSound este mostenita din clasa Animal
return 0;
}
</syntaxhighlight>

În exemplul de mai sus, clasa <code>Cat</code> preia toți membrii din clasa <code>Animal</code> și adaugă un câmp <code>mLives</code> și un constructor fără argumente. S-a introdus, de asemenea, un nou modificator de acces, <code>protected</code>, care permite accesul la membrul respectiv atât din clasa curentă cât și din orice clasă derivată din clasa curentă, dar nu și din alte clase sau funcții.

Se observă, de asemenea, că moștenirea a fost declarată publică. Există două timpuri de moșteniri:
# publică
# privată

Relativ la tipul de moștenire, mai jos este prezentat modul în care se preiau membrii din clasa de bază:
{| class="wikitable"
|+ Accesul asupra membrilor moșteniți
|-
! Protecția in clasa de baza !! Modificatorul de acces utilizat în lista claselor de bază !! Dreptul de acces în clasa derivată
|-
| public || public || public
|-
| private || public || inaccesibil
|-
| protected || public || protected
|-
| public || private || private
|-
| private || private || inaccesibil
|-
| protected || private || private
|}

<div class="regula"><font color="#ff0000">Atenție: </font>A doua diferență între <code>class</code> și <code>struct</code> este că pentru prima, moștenirea implicită este '''private''' iar pentru a doua este '''public'''.</div>

== Apelul constructorului superclasei ==

Când se instanțiază o clasă derivată, constructorul acestei clase se ocupă de inițializarea câmpurilor definite în clasa derivată. Pentru a inițializa câmpurile din clasa de bază, este necesar să apelăm constructorul ei. Prin urmare:

<div class="regula"><font color="#ff0000">Atenție: </font>Obligatoriu, constructorul unei clase derivate trebuie să apeleze constructorul clasei de bază. Dacă acest apel nu se face explicit, compilatorul va introduce un apel către constructorul clasei de bază fără argumente. Dacă acesta lipsește, apelul către constructorul clasei de bază trebuie făcut explicit, altfel se va genera o eroare de compilare.</div>

Apelul constructorului superclasei se face folosind aceeași sintaxă ca pentru inițializarea câmpurilor:

<syntaxhighlight lang="C++" line highlight="32">
class Animal {
std::string mName;
std::string mColor;
int mAge;
protected:
bool mHasFeathers;

public:
Animal(const std::string & name, const std::string & color) : mName(name), mColor(color) {
}

void makeSound() const {
printf("Animal %s makes a sound!\n", mName.c_str());
}

// this is a getter method
std::string getName() const {
return mName;
}

// this is a setter method
void setAge(int age) {
if(age > 0) {
mAge = age;
}
}
};

class Cat : public Animal {
unsigned int mLives;
public:
Cat(const std::string & name, const std::string & color) : Animal(name, color), mLives(9) {
mHasFeathers = false;
}
};
</syntaxhighlight>

= Ascunderea metodelor =

În anumite situații, există nevoia ca o anumită metodă care este moștenită din clasa de bază să se comporte altfel în clasa derivată. Putem realiza acest lucru reimplementând metoda respectivă, cu aceeași semnătură, în clasa derivată. Acest mecanism se numește ascundere (hiding):

<syntaxhighlight lang="C++" line highlight="39-41">
#include <string>
#include <cstdio>

class Animal {
std::string mName;
std::string mColor;
int mAge;
protected:
bool mHasFeathers;

public:
Animal(const std::string & name, const std::string & color) : mName(name), mColor(color) {
}

void makeSound() const {
printf("Animal %s makes a sound!\n", mName.c_str());
}

// this is a getter method
std::string getName() const {
return mName;
}

// this is a setter method
void setAge(int age) {
if(age > 0) {
mAge = age;
}
}
};

class Cat : public Animal {
unsigned int mLives;
public:
Cat(const std::string & name, const std::string & color) : Animal(name, color), mLives(9) {
mHasFeathers = false;
}

void makeSound() const {
printf("Cat %s meows!\n", getName().c_str());
}
};

int main() {
Animal animal("Rex", "black");
animal.makeSound();
Cat cat("Spot", "tabby");
cat.makeSound();
return 0;
}
</syntaxhighlight>

Ieșire:
<syntaxhighlight lang="text">
Animal Rex makes a sound!
Cat Spot meows!
</syntaxhighlight>

= Polimorfismul =

== Introducere ==
Polimorfismul -- din greacă "poly" (mai multe) and "morphe" (forme) -- se referă la faptul că un obiect care este de tipul unei clase derivate, este în același timp și de tipul clasei de bază. Altfel spus:

<div class="regula"><font color="#ff0000">Atenție: </font>Dacă o clasă <code>B</code> extinde (direct sau indirect) o clasă <code>A</code>, atunci un obiect <code>b</code> de tipul <code>B</code> este în același timp și de tipul <code>A</code>.</div>

Folosind acest concept, care este implementat și în limbajul C++, se pot utiliza pointeri sau referințe de un tip <code>T</code> pentru a referi obiecte de tipuri derivate din <code>T</code>.

== Exemplu ==

<syntaxhighlight lang="C++" line highlight="50">
#include <string>
#include <cstdio>

class Animal {
std::string mName;
std::string mColor;
int mAge;
protected:
bool mHasFeathers;

public:
Animal(const std::string & name, const std::string & color) : mName(name), mColor(color) {
}

void makeSound() const {
printf("Animal %s makes a sound!\n", mName.c_str());
}

// this is a getter method
std::string getName() const {
return mName;
}

// this is a setter method
void setAge(int age) {
if(age > 0) {
mAge = age;
}
}
};

class Cat : public Animal {
unsigned int mLives;
public:
Cat(const std::string & name, const std::string & color) : Animal(name, color), mLives(9) {
mHasFeathers = false;
}

void makeSound() const {
printf("Cat %s meows!\n", getName().c_str());
}
};

int main() {
Animal animal("Rex", "black");
Cat cat("Spot", "tabby");

Animal & animalRef = animal;
Cat & catRef = cat;
Animal & catRef2 = cat;

animalRef.makeSound();
catRef.makeSound();
catRef2.makeSound();

return 0;
}
</syntaxhighlight>

Ieșire:
<syntaxhighlight lang="text">
Animal Rex makes a sound!
Cat Spot meows!
Animal Spot makes a sound!
</syntaxhighlight>

Se vede că pe linia 50 de mai sus, avem o referință de tip <code>Animal</code> la un obiect de tip <code>Cat</code>. Acest lucru este posibil pentru că o <code>Cat</code> este în același timp și un <code>Animal</code> (deoarece <code>Cat</code> extinde <code>Animal</code>). Totuși, se poate observa din textul de ieșire că deși referințele <code>catRef</code> și <code>catRef2</code> sunt către același obiect (de tip <code>Cat</code>), apelul metodei <code>makeSound</code> se face în funcție de tipul referinței, nu de tipul obiectului. Există însă scenarii în care se dorește comportamentul invers, anume apelul metodei în funcție de tipul obiectului, nu de tipul referinței cu care este accesat. Astfel, se introduce conceptul de '''metodă virtuală'''.

= Metode virtuale și suprascrierea metodelor =
== Introducere ==

Dacă o metodă este declarată virtuală, folosind cuvântul cheie <code>virtual</code> plasat în fața tipului întors, atunci reimplementarea acesteia în clasele derivate se numește '''suprascriere'''. Apelul unei metode virtuale folosind o referință de alt tip decât al clasei din care face parte obiectul, va apela metoda corespunzătoare obiectului în sine, nu cea care aparține tipului referinței.

== Exemplu ==
<syntaxhighlight lang="C++" line highlight="15,39">
#include <string>
#include <cstdio>

class Animal {
std::string mName;
std::string mColor;
int mAge;
protected:
bool mHasFeathers;

public:
Animal(const std::string & name, const std::string & color) : mName(name), mColor(color) {
}

virtual void makeSound() const {
printf("Animal %s makes a sound!\n", mName.c_str());
}

// this is a getter method
std::string getName() const {
return mName;
}

// this is a setter method
void setAge(int age) {
if(age > 0) {
mAge = age;
}
}
};

class Cat : public Animal {
unsigned int mLives;
public:
Cat(const std::string & name, const std::string & color) : Animal(name, color), mLives(9) {
mHasFeathers = false;
}

void makeSound() const override {
printf("Cat %s meows!\n", getName().c_str());
}
};

int main() {
Animal animal("Rex", "black");
Cat cat("Spot", "tabby");

Animal & animalRef = animal;
Cat & catRef = cat;
Animal & catRef2 = cat;

animalRef.makeSound();
catRef.makeSound();
catRef2.makeSound();

return 0;
}
</syntaxhighlight>

Ieșire:
<syntaxhighlight lang="text">
Animal Rex makes a sound!
Cat Spot meows!
Cat Spot meows!
</syntaxhighlight>

<div class="sfat"><font color="darkgreen">Sfat:</font> Când se suprascrie o metodă într-o clasă derivată, este recomandat să plasați înainte de acolada deschisă care implementează metoda cuvântul cheie <code>override</code>. Deși acest lucru nu este obligatoriu, vă va avertiza printr-o eroare de compilare dacă suprascrierea nu se face corect (de exemplu dacă metoda din clasa de bază nu este declarată virtuală).</div>

= Metode pur virtuale și clase abstracte =

== Introducere ==

În anumite situații, o metodă virtuală nu poate avea o implementare în clasa de bază, pentru că nu este cunoscut modul în care aceasta se comportă. În această situație, metoda poate fi definită ca fiind '''pur virtuală''', adică o metodă fără implementare, dar care este totuși declarată în cadrul clasei.

<div class="regula"><font color="#ff0000">Atenție: </font>Dacă o clasă conține cel puțin o metodă pur virtuală aceasta se numește '''clasă abstractă''' și nu poate fi instanțiată.</div>

Dacă am crea un obiect de tipul respectiv, atunci nu am putea apela metoda pur virtuală pentru că implementarea aceasteia lipsește. Clasele abstracte se pot folosi numai pentru a fi extinse, și metodele pur virtuale trebuie suprascrise în clasele derivate. Dacă cel puțin una din metodele pur virtuale nu este suprascrisă, atunci clasa derivată este la rândul ei abstractă.

== Exemplu ==

<syntaxhighlight lang="C++" line highlight="24,45">
#include <string>
#include <cstdio>

class Animal {
std::string mName;
std::string mColor;
int mAge;
protected:
bool mHasFeathers;

public:
Animal(const std::string & name, const std::string & color) : mName(name), mColor(color) {
}

virtual void makeSound() const {
printf("Animal %s makes a sound!\n", mName.c_str());
}

// this is a getter method
std::string getName() const {
return mName;
}

virtual int getNumberOfLegs() const = 0;

// this is a setter method
void setAge(int age) {
if(age > 0) {
mAge = age;
}
}
};

class Cat : public Animal {
unsigned int mLives;
public:
Cat(const std::string & name, const std::string & color) : Animal(name, color), mLives(9) {
mHasFeathers = false;
}

void makeSound() const override {
printf("Cat %s meows!\n", getName().c_str());
}

int getNumberOfLegs() const override {
return 4;
}
};

int main() {
Animal animal("Rex", "black"); // eroare de compilare, Animal este clasa abstracta

Cat cat("Spot", "tabby");
Cat & catRef = cat;
Animal & catRef2 = cat;

catRef.makeSound();
catRef2.makeSound();

return 0;
}
</syntaxhighlight>