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

Motor_Groups should fulfill the Container named requirements #490

Open
djava opened this issue Jan 16, 2023 · 1 comment
Open

Motor_Groups should fulfill the Container named requirements #490

djava opened this issue Jan 16, 2023 · 1 comment

Comments

@djava
Copy link
Contributor

djava commented Jan 16, 2023

Building on #450 and #463, for pros::Motor_Group to be fully treatable as a standard container, it should fulfill at the very least the standard's Container named requirements.

Additionally, Motor_Group could likely also fulfill all the named requirements that std::vector does (with the exception of AllocatorAwareContainer), since its underlying data structure is a vector. Those additional named requirements would be SequenceContainer, ContiguousContainer, and ReversibleContainer (although this one is not particularly relevant to any of Motor_Group's potential use-cases).

The main benefits of this are:

  • compatibility with range-based for loops
  • compatibility with std algorithms
  • following C++ standard best practice for how a container-like object should behave

I don't believe that this would be a huge effort, since most of the required types and calls would be redirected to the underlying vector. (i.e. iterator Motor_Group::begin() { return arr.begin(); }) This can certainly be targeted for the PROS 4 release, since it's definitely not urgent.

I'm not sure yet how everything will work with the new PROS 4 design for Motor_Group but I'd imagine that the solution used for Motor_Group::operator[] in PROS 4 will be transferable to these requirements.

@Richard-Stump
Copy link
Contributor

Richard-Stump commented Jan 17, 2023

Thank you for the idea! I personally like this idea, but we are currently rewriting the logistics of how motor groups work for PROS 4. We can look at this again when we have a beta version of PROS 4 out, or as a 4.1 feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants