Replace boost::iterator_range usage for ranges of UsdPrims
#2280
Conversation
nvmkuruc
force-pushed
the
usdrange
branch
2 times, most recently
from
b9da8b7
to
f58f549
Compare
|
Filed as internal issue #USD-8018 |
nvmkuruc
force-pushed
the
usdrange
branch
3 times, most recently
from
4be23f5
to
828456d
Compare
| UsdPrimSiblingRange(UsdPrimSiblingIterator begin, | ||
| UsdPrimSiblingIterator end) : _begin(begin), | ||
| _end(end) {} | ||
|
|
There was a problem hiding this comment.
I'm assuming these templated constructors and assignment operators are to perfectly match what boost::iterator_range provides?
I feel like these are overkill given that I would never expect anyone to construct a sibling range without calling the Get*Children functions that return them (and it would be honestly dangerous to do so since sibling iteration is a proxy). How do you feel about just leaving these out?
| /// Iterator reference_type. | ||
| typedef iterator::reference reference; | ||
|
|
||
| UsdPrimSiblingRange() = default; |
There was a problem hiding this comment.
I'm curious about having to explicit default the implicit copy/move constructors/assignment. Is this necessary because the templated constructors below create a user-defined copy constuctor when expanded against UsdPrimSiblingRange?
If we get rid of the templated constructor/assignment, can we get rid of these declarations too?
| return lhs.equal(rhs); | ||
| } | ||
|
|
||
| /// Equality comparison. |
There was a problem hiding this comment.
I'm also wondering if the template comparision operators are really needed (though they seem slightly less unneeded than the templated constructors.
| typedef iterator::value_type value_type; | ||
| /// Iterator reference_type. | ||
| typedef iterator::reference reference; | ||
|
|
There was a problem hiding this comment.
Exact same comments for this range as the sibling range.
Description of Change(s)
Depends on #2235
UsdPrim{Sibling,Subtree}Rangeusing the existing doxygen stubscbeginandcendmethodsboost::iterator_rangeinpxr/usd/usd/primData.hUsdPrimSubtreeRangetotestUsdPrimGetDescendantsFixes Issue(s)
boost::iterator_rangecan be replaced with explicit range types #2276