Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor of PcapRemoteDeviceList's factory functions. #1476

Merged
merged 10 commits into from
Jul 17, 2024

Conversation

Dimi1010
Copy link
Collaborator

@Dimi1010 Dimi1010 commented Jun 30, 2024

Part of #1431. implements point 6.

  • Added a new factory function createRemoteDeviceList with overloads with/without authentication returning unique_ptr.
  • Deprecated the old getRemoteDeviceList due to the functions returning raw pointers.
  • Removed default constructor of PcapRemoteDeviceList
  • Added parameterized constructor to PcapRemoteDeviceList for detailed initialization.
  • Removed unused private methods:
    • setRemoteMachineIpAddress
    • setRemoteMachinePort
    • setRemoteAuthentication
  • Changed typedefs to Cpp11 standard.
  • Typo fixes

Dimi1010 added 5 commits June 30, 2024 20:11
- Introduced `createRemoteDeviceList` static methods in `PcapRemoteDeviceList` for creating and managing remote device lists using `std::unique_ptr`, enhancing memory management and safety.
- Modified existing `getRemoteDeviceList` methods to utilize new `createRemoteDeviceList` methods, maintaining backward compatibility by returning raw pointers through `.release()`.
- Adopted smart pointers (`std::unique_ptr`) in the implementation for automatic memory cleanup, reducing the risk of memory leaks and improving code maintainability.
- Modernized the codebase by leveraging C++11 smart pointers, simplifying resource management and providing a clearer, more flexible API for handling remote device lists with and without authentication.
Modernized the syntax for defining iterator and const iterator type aliases in `PcapRemoteDeviceList.h` within the `pcpp` namespace. Replaced traditional `typedef` with the `using` syntax for `RemoteDeviceListIterator` and `ConstRemoteDeviceListIterator`. These changes enhance code readability and align with modern C++ best practices without altering functionality.
- Removed the default constructor of 'PcapRemoteDeviceList'.
- Added a new constructor to `PcapRemoteDeviceList` for initializing with detailed remote machine info and authentication.
- Corrected typographical errors in comments for better documentation clarity.
- Improved const-correctness in `createRemoteDeviceList` by changing `remoteAuth` parameter type.
- Refactored device creation logic in `createRemoteDeviceList` for clearer error handling and separation of concerns.
- Enhanced error handling in device creation to prevent memory leaks on exceptions.
- Transitioned to using `std::shared_ptr<PcapRemoteAuthentication>` for better memory management in device creation.
- Simplified authentication object handling by converting to `std::shared_ptr` early in the device creation process.
- Included DeprecationUtils.h in PcapRemoteDeviceList.h to mark certain functionalities as deprecated, indicating a move towards newer alternatives.
- Updated the private constructor comment in PcapRemoteDeviceList to recommend using `createRemoteDeviceList` for instance creation, reflecting a shift to a new factory method.
- Deprecated two static factory functions, `getRemoteDeviceList(const IPAddress& ipAddress, uint16_t port)` and `getRemoteDeviceList(const IPAddress& ipAddress, uint16_t port, PcapRemoteAuthentication* remoteAuth)`, in favor of `createRemoteDeviceList`, enhancing memory safety and functionality.

std::unique_ptr<PcapRemoteDeviceList> PcapRemoteDeviceList::createRemoteDeviceList(const IPAddress& ipAddress, uint16_t port, PcapRemoteAuthentication const* remoteAuth)
{
std::shared_ptr<PcapRemoteAuthentication> sRemoteAuth;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the naming sRemoteAuth, it's not the convention in this project.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

however, we don't have many std::shared_ptr currently. So if other people agree with this, this can become the official coding style.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally, I had a private overload where remoteAuth was a shared ptr to avoid that, but scrapped it as it was not strictly nessesary.

Perhaps that would be a better solution?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tbh, I just named it that way coz i needed the variable to not conflict. If there are suggestions on a potential name, i'm happy to hear them.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed it to remoteAuthCopy to be more explicit that its a copy in 4f66704. Not sure if it should be remoteAuthCopy or pRemoteAuthCopy tho.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine with either, but seems pXXX is more common in the codebase?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated cf3d1c2

@tigercosmos tigercosmos added this to the Augest 2024 Release milestone Jul 5, 2024
@tigercosmos tigercosmos merged commit 1a436d9 into seladb:dev Jul 17, 2024
38 checks passed
@Dimi1010 Dimi1010 deleted the refactor/remote-list-factories branch July 19, 2024 09:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants