r/cpp • u/User_Deprecated • 6d ago

C++26: std::inplace_vector

https://www.sandordargo.com/blog/2026/08/26/cpp26-inplace-vector
171 Upvotes

94% Upvoted

121 comments sorted by

View all comments

-2

u/johannes1971 6d ago

unchecked_push_back

Is it really necessary to add new forms of UB? For people that apparently can't spend the nanosecond needed for the if-statement, would you ever use any data structure you didn't write yourself?

6

u/_Noreturn 6d ago

would you ever use any data structure you didn't write yourself?

Yes?

Is it really necessary to add new forms of UB? For people that apparently can't spend the nanosecond needed for the if-statement,

Honestly I see this as very very unnecessary, they should instead add resize_and_overwrite style init, because where would you realistically use this? because if anything this will have bad performance than a simple memcpy style init. Also the same behavior could be replaced with *try_push_back where you always dereference the pointer.

6

u/unchangeableusername 6d ago

Also the same behavior could be replaced with *try_push_back where you always dereference the pointer.

I feel like this ought to be the case but this godbolt example shows that it's not quite the same.

Honestly I see this as very very unnecessary

I'd argue that the unchecked_* functions are useful when the next value you push_back is dependent on the previous values (and can guarantee size never exceeds capacity). Recording states when traversing a DFA is the first example I can think of, although I don't how common doing stuff like this is. But I did find a 7% performance improvement for this specific use case when using a hacky unchecked_push_back equivalent for std::vector over the regular push_back (reserve was called beforehand in both situations).

2

u/tialaramex 4d ago

Of course if you v.clear() in those examples, ensuring the compiler knows how big v is, the optimiser gives the same result for both cases.

Your traverse a DFA example sounds plausible because the optimiser probably can't see why it can elide the capacity check, but I'd be very sceptical without seeing a full working system that you can win 7% perf.

If you're correct about 7% perf then unchecked_push_back makes sense - a lot of things are worth doing for 7% perf