You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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'sContainer
named requirements.Additionally, Motor_Group could likely also fulfill all the named requirements that
std::vector
does (with the exception ofAllocatorAwareContainer
), since its underlying data structure is a vector. Those additional named requirements would beSequenceContainer
,ContiguousContainer
, andReversibleContainer
(although this one is not particularly relevant to any ofMotor_Group
's potential use-cases).The main benefits of this are:
for
loopsstd
algorithmsI 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 forMotor_Group::operator[]
in PROS 4 will be transferable to these requirements.The text was updated successfully, but these errors were encountered: