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

PROS 3.8: .at() method for motor groups #494

Closed
Richard-Stump opened this issue Jan 24, 2023 · 2 comments
Closed

PROS 3.8: .at() method for motor groups #494

Richard-Stump opened this issue Jan 24, 2023 · 2 comments
Assignees

Comments

@Richard-Stump
Copy link
Contributor

Richard-Stump commented Jan 24, 2023

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();
@djava
Copy link
Contributor

djava commented Jan 24, 2023

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.

@Richard-Stump
Copy link
Contributor Author

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.

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

4 participants