3 ms·

.. on a vector of trivial types. If we have to call a non-trivial destructor for the item being removed, the check stops being significant. Then there can't be

.. on a vector of trivial types. If we have to call a non-trivial destructor for the item being removed, the check stops being significant. Then there can't be a pop without a push or some other operation that filled the vector, and that operation necessarily has the checks and branches to allocate more space if necessary. The compiler should also be smart enough to branch forward to the throw so the branch predictor assumes not taken by default, so this is still cheap af. This is "fairly bad" for performance maybe 1% of the time. For the other 99%, you'd make pop_back check and throw and keep the unchecked version as pop_back_fast or something like that. That's what a sane API would look like.

fooker 4y ago
>If we have to call a non-trivial destructor for the item being removed, the check stops being significant. This is a complicated cost model which compilers usually avoid. >The compiler should also be smart enough. It isn't. > That's what a sane API would look like. Awesome, there is nothing stopping you from creating your own functions which add this check.
- mike_hock 4y ago
  > It isn't. It definitely is. Go try it on godbolt. > Awesome, there is nothing stopping you from creating your own functions which add this check. Thanks for your amazing insight. STL is lacking? Nothing is stopping us from writing our own functions. STL is garbage? Nothing is stopping us from writing our own replacement. The whole language is garbage? Nothing is stopping us from creating a new one from scratch. Really, you've found the solution to everything.