RAII / resource ownership cleanup in selected C++ (Tello decoder, hospital person plugin, exercise templates)

[shailigandhi-oss]

Summary

I’d like to contribute small, behavior-preserving refactors that apply RAII-style resource management in a few C++ areas: clearer ownership, safer teardown on errors, and less reliance on manual new/delete or raw OS handles. I’m opening this under Ideas to check whether maintainers want this direction before I invest in PRs and build/test on your stack.

Motivation (what’s fragile today)

Several spots pair manual acquisition with manual release or return raw owning pointers without a documented owner:

• FFmpeg / libav: decoder context, parser, frames, and AVPacket need consistent free/close paths. If initialization fails partway through the constructor, partial state may not match what a destructor would clean up. Mixing new/delete for AVPacket with C APIs also splits ownership style.
• Socket FDs: a UDP server implemented with a raw int and close() in a plugin destructor works until refactors add early returns, error paths, or unclear initialization order; a scoped FD type makes “close exactly once” a local invariant.
• Exercise templates: new in APIs like get_laser_data() (raw pointer return) or new Lap() passed into async WebSocket code makes leaks and double-free risks likely for students and reviewers unless ownership is explicit.

This is less about “performance optimization” and more about robustness, exception safety where applicable, and maintainability.

Proposed scope (concrete locations)

Area	Repository	Path(s)
H.264 decoder wrapper	RoboticsInfrastructure	CustomRobots/tello_phy/tello_ros/tello_driver/h264decoder/h264decoder.{hpp,cpp}
Gazebo person + UDP teleop	RoboticsInfrastructure	CustomRobots/amazon_hospital/src/person.cpp
Vacuum HAL API	RoboticsAcademy	exercises/vacuum_cleaner/cpp_template/HAL.hpp (get_laser_data)
Follow-line Web GUI	RoboticsAcademy	exercises/follow_line/cpp_template/WebGUI.hpp (Lap lifetime vs session)

I would not propose edits to vendored/third-party blobs such as json.hpp.

What I’d change (high level)

• std::unique_ptr (with custom deleters where needed) or small wrapper types for FFmpeg handles and for the packet, so cleanup is uniform and constructor failure is easier to make leak-free.
• A scoped socket / FD helper (or equivalent) for the person plugin’s UDP server, aligned with how you prefer POSIX code in this repo.
• Exercise templates: prefer by-value LaserData, std::optional, or smart pointers with documented ownership; same for Lap relative to the Beast session lifetime.

Ask to maintainers

1. Is this kind of cleanup in scope and welcome?
2. Should infra changes go to RoboticsInfrastructure and template-only changes to RoboticsAcademy, with submodule bumps handled your usual way?
3. Is there a preferred order (e.g. h264decoder only first)?
4. Any C++ standard or style I should follow beyond the Academy contributing docs?

If this sounds good, I’ll prepare a minimal, testable PR (with build/runtime validation as you require in CONTRIBUTING) starting from the area you indicate first.

Thanks for considering it.
@jmplaza

[jmplaza]

Hi @shailigandhi-oss ,

I'm sorry but I don't understand your proposal. It is not directly related to project #2 at all. It seems to me that you have not properly understood the RoboticsAcademy base code. Feel free to USE RoboticsAcademy and create your solutions for several available exercises. After that, study the base source code as RoboticsAcademy as developer. Those steps will give you a good background to send a meaninful proposal. And focus on the open issues at RoboticsAcademy repo. Take a look at #3381.

In addition, I'm afraid is too late for a sensible feedback from the potential mentors and for meaningful contributions on your side before the submission deadline. Just follow the applicant instructions, fill the required form and take a look at https://github.com/orgs/JdeRobot/discussions/383.

[shailigandhi-oss]

Hi, @jmplaza thank you so much for taking the time to share this feedback — I really appreciate it!
I want to clarify that I’ve already had my proposal approved by mentors and submitted it before the deadline. My comment here wasn’t about the GSoC proposal itself — I was simply exploring ideas to contribute to the repository more broadly, independent of GSoC.
I apologize if my message came across as an unrelated or underprepared proposal — that wasn’t my intent at all. I’ll make sure to go through RoboticsAcademy more thoroughly as both a user and a developer, and engage more meaningfully with the open issues, including #3381.
Thanks again for the guidance, I’ll be more careful about how I frame future discussions!