point / tripoint / rectangle / box refactoring and enhancements #32242
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
SUMMARY: None
Purpose of change
Needed some new features on
point
andtripoint
for another branch I'm working on.Want it to be easier and clearer to use bounds-checking with rectangles and boxes.
Describe the solution
Some misc changes
point
.to_string
topoint
andtripoint
.StringMaker
specializations forbox
andrectangle
.tripoint::xy
to fetch thepoint
part of it.point.cpp
.Overhaul of
generic_inbounds
generic_inbounds
, have two member functions on each ofrectangle
andbox
to test bounds.clearance
parameter, have two names for the two common bounds types (inclusive and half-open ranges). Addbox::shrink
for the one use case that really requiredclearance
.constexpr
.The main goal here is to make it easier to use these bounds tests in fewer lines of code for common cases. I also think the member function form reads more smoothly in code.
Describe alternatives you've considered
Could have kept the bounds-checking things as free functions.
Additional context
Ultimately in support of #32017, but multiple steps removed.