Make inplace_vectorconstexpr friendly by providing an T-based array storage alternative that avoids the needs of reinterpret_cast.
This storage alternative is only selected when std::is_trivial(T), as that's the requirement for enabling constexpr in the paper.
Adds constexpr based tests.
Related sections in paper:
constexpr support
Note: this revision brings back this section which was dropped in R8 because per LEWG discussion, LEWG thought that this whole type was implementable within constexpr for all types. The design intent of LEWG was to make it "as constexpr as possible."
The API of inplace_vector<T, Capacity> can be used in constexpr-contexts if is_trivially_copyable_v, is_default_constructible_v, and is_trivially_destructible are true. This proposal only supports using the constexpr methods in constant expressions if is_trivial_t is true.
The implementation cost of this is small. The prototye implementation specializes the storage to use a C array with value-initialized elements.
This negatively impacts the algorithmic complexity of inplace_vector constructors for these types from O(size) to O(capacity). When value-initialization takes place at run-time, this difference is significant.
Vectors with large capacity requirements are better served by vector instead.
Make
inplace_vector
constexpr
friendly by providing an T-based array storage alternative that avoids the needs ofreinterpret_cast
.This storage alternative is only selected when
std::is_trivial(T)
, as that's the requirement for enabling constexpr in the paper.Adds constexpr based tests.
Related sections in paper:
All member functions should be constexpr.
Closes #17