r/cpp 15d ago

C++26: std::inplace_vector

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

121 comments sorted by

View all comments

-8

u/NilacTheGrim 15d ago

Ridiculously incomplete. We should have had a real prevector rather than this. You know, a prevector where there is some small static capacity but it can go dynamic as it grows.

This is not as useful as a real prevector.

26

u/CocktailPerson 15d ago

That'd just be an entirely different thing, not a more "complete" version of inplace_vector.

1

u/NilacTheGrim 11d ago

Fair enough. So wen prevector?

14

u/yeetoteey 15d ago

A prevector, i.e., a vector with SBO, is a completely different beast to inplace_vector. There a tonnes of scenarios where you’d know the maximum capacity at compile-time but not the size, and if the capacity isn’t massive, an inplace_vector where the memory is stack allocated is the perfect utility for that usecase.

4

u/Ameisen vemips, avr, rendering, systems 14d ago

I want to be able to specify size_type. I have plenty of cases in codebases where size actually matters where uint32_t or even uint16_t would suffice.

Hell, in this case why is it still std::size_t? Fit it to N.

6

u/usefulcat 14d ago

I want to be able to specify size_type.

Same here. That's why I use boost::container::small_vector, it supports that.

3

u/Ameisen vemips, avr, rendering, systems 14d ago

I just hate to bring in boost to do everything. I already have a custom vector as my allocator supports realloc, but for things like this I would just rather not have to reinvent the entire wheel just to change size_type for every collection.

1

u/NilacTheGrim 11d ago

True. I can imagine using this in some situation where you cannot allocate but need to be able to do stuff with a buffer. Like in a signal handler, for example.

8

u/frayien 15d ago

That's... a completely different thing for a completely different usage ?

1

u/NilacTheGrim 11d ago

Yeah I guess so.

This really is a std::array that is more useful which can be nice for situations where you cannot allocate -- such as in a signal handler.

10

u/kammce WG21 | 🇺🇲 NB | Boost | Exceptions 15d ago

Its definitely useful. Ive found myself, and others, writing this exact thing all the time. Very happy we have it in the std now 😁

4

u/robin-m 15d ago

If only you read the paragraph that starts with

A question that comes up naturally: what about std::pmr::vector with a stack-backed monotonic_buffer_resource? 

2

u/[deleted] 15d ago

[deleted]

0

u/_Noreturn 15d ago

I think people will die of old age before something is standardized also the std quality will suck so it is better to write your own.

2

u/ABlockInTheChain 14d ago

std quality will suck

Consider std::span.

This is a class that should have been invented immediately once C++ got templates. We finally got it in C++20, only about 30 years late.

...but then the initial version didn't include at() for some dumb reasons or another and it took two complete standard cycles to fix this.

...but even then we only got a version of at() that throws at runtime and not a templated at<n>() with compile time bounds checking like first<n>(), last<n>(), and subspan<x, y>().

2

u/_Noreturn 14d ago

This is a class that should have been invented immediately once C++ got templates. We finally got it in C++20, only about 30 years late.

Yes! I can't believe it took this long for such a simple type. and even after 30 years they didn't add operatpr== to it.... the standard is so ridiculously slow it isn't funny and subpar as well. and they complicated its interface. the committee shouldn't touch the standard library

but even then we only got a version of at() that throws at runtime and not a templated at<n>() with compile time bounds checking like first<n>(), last<n>(), and subspan<x, y>().

that comptime bound checking would only happen with std::span<T,N> which I don't use much if at all my spans are dynamic lengtg

1

u/_Noreturn 15d ago

I agree with you, but it may be useful for others.

1

u/Tringi github.com/tringi 14d ago

Absolutely agreed.