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
This is mainly regarding std::vector. We use vectors throughout Kinoko, even though Nintendo didn't have them. What we end up effectively having is some container always having a fixed upper bound, whereas std::vector is resizable. We could use spans, but then it's annoying to have to manage that every time we run into this scenario.
Explore why we should make our own container type and discuss some of the unique implementation details we could include, such as having ASSERTs in our push_back / emplace_back calls.
The text was updated successfully, but these errors were encountered:
std::span is only usable when the size and capacity of an array are the same. std::vector allows for incongruency between size and capacity, but handles cases in which the size can be greater than the capacity. We would prefer a container that guarantees the size will always be below or at a specified capacity, thus eliminating a lot of overhead.
This is mainly regarding std::vector. We use vectors throughout Kinoko, even though Nintendo didn't have them. What we end up effectively having is some container always having a fixed upper bound, whereas std::vector is resizable. We could use spans, but then it's annoying to have to manage that every time we run into this scenario.
Explore why we should make our own container type and discuss some of the unique implementation details we could include, such as having
ASSERT
s in ourpush_back
/emplace_back
calls.The text was updated successfully, but these errors were encountered: