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
A use case where a motor group is in a smart pointer leads to some issues if the user needs to access individual motors. The operator overloads for smart pointers do not play nicely with the array overload on the motor groups.
std::shared_ptr<pros::Motor_Group> motor_group = ...;
(*motor_group)[idx].get_voltage(); // Does not compile
*(motor_group)[idx].get_voltate(); // Does not compile
motor_group.get()[idx].get_voltate(); // Compiles and works
Instead, adding a method .at() to the motor groups that does the same thing as the array operator would be more clear for users in this case:
motor_group->at(idx).get_voltate();
The text was updated successfully, but these errors were encountered:
Just noting this would be fulfilled by #490 😏 (jk)
I'd recommend making sure that .at() bounds-checks and throws std::out_of_range, as convention for container classes is that operator[] is not bounds-checked, but .at() is.
Since motor groups in PROS 3 are just a class holding a std::vector, the .at() function will likely just call the vector's .at() function and get that functionality automatically.
A use case where a motor group is in a smart pointer leads to some issues if the user needs to access individual motors. The operator overloads for smart pointers do not play nicely with the array overload on the motor groups.
Instead, adding a method
.at()
to the motor groups that does the same thing as the array operator would be more clear for users in this case:motor_group->at(idx).get_voltate();
The text was updated successfully, but these errors were encountered: