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
Remove sf::View::reset
in favor of assignment operations
#2942
base: master
Are you sure you want to change the base?
Conversation
Pull Request Test Coverage Report for Build 9145160170Details
💛 - Coveralls |
Worth noting that reset method was not doing the same as assigning a new constructed view because it was not changing viewport and scissor. |
Good point. I wonder if that is an oversight or intentional. What could be the use case for resetting part of a view but not all of it? |
Rebased on |
I did some digging in the commit history.
A similar story is feasible for I think |
It's rare that a type truly needs a .reset function. Copy/move assignment typically accomplishes the same thing with less code and is easier to maintain since it doesn't require updating your .reset() function as new data members are added. To reset a type is conceptually the same thing as simply assigning from a newly constructed instance of the same type.
Description
It's rare that a type truly needs a .reset function. Copy/move assignment typically accomplishes the same thing with less code and is easier to maintain since it doesn't require updating your .reset() function as new data members are added.
To reset a type is conceptually the same thing as simply assigning from a newly constructed instance of the same type.