Add support for inplace_vector

[20162026]

#1676

[20162026]

It works, but I'm not sure if it is worthy to be merged becouse:

1. only json read is implemented ( beve dose not use emplace_back and would require more modifications, didn't check others)
2. serializing into inplace_vector<char, N> without exceptions is tricky becouse of multiple resize calls
3. beman::inplace_vector is not fully implemented (e.g. <=> is broken, no proper constexpr handling, init list only works with exceptions enabled, build fails with clang fnoexcept)

[stephenberry]

Thanks for making this merge request! I do like the idea of inplace_vector support and this gives a starting point for experimenting with that support. I'll look into them when I get some time. I wouldn't mind merging in a solution that is 90% there and improving it over time.

[20162026]

I will try to bring beman.inplace_vector into a somewhat usable state before continuing with this PR.

If anyone knows of a good inplace_vector implementation that doesn’t require a full custom STL, please let me know :)

[stephenberry]

@20162026, I walked AI through generating an inplace_vector implementation based only the STL and using C++23. I've added it to Glaze: glaze/containers/inplace_vector.hpp. Will need more testing, but I think this should be a good approach for implementing it until new get it in C++26. The goal will be to make it efficient while complying with the future standard.

[stephenberry]

@20162026, I think glz::inplace_vector is looking pretty good now. It could probably be optimized in a few cases, but it should be high performance for trivial types. Let me know what you think. I added a bunch of unit tests to make sure things are working as expected.

[20162026]

@stephenberry would you be interested in supporting freestanding inplace_vector in glaze, that would =delete all of the potentaly throwing functions? According to spec all throwing functions are marked with 'freestanding-deleted` which means its up to implementer if they want to leave them or remove.

deleting throwing/aborting functions is extremely convenient for embedded, as you get compiler warning instead of runtime error when trying to use potentially throwing functions. But it would require at least some minor concept changes as it will no longer be direct vector replacement.

also as a sidenot, would you like me to add pre-commit for formatting?

[stephenberry]

@20162026, yes I think 'freestanding-deleted' makes sense. Go ahead.

And, per your side note about formatting, Glaze is actually setup to use clang-format (just upgraded to v20) automatically when the code gets merged, so don't worry about formatting this merge request.

[20162026]

@stephenberry is there actually performance gain in release build when using stuff like

if constexpr (std::is_trivially_copyable_v<T>) {
   std::memcpy(this->data_ptr() + storage_size(), &x, sizeof(T));
}
else {
   std::construct_at(this->data_ptr() + storage_size(), x);
}

or

if constexpr (std::is_trivially_copyable_v<T>) {
 return std::memcmp(lhs.data_ptr(), rhs.data_ptr(), lhs.storage_size() * sizeof(T)) == 0;
}
else {
 return std::equal(lhs.begin(), lhs.end(), rhs.begin());
}

I would expect compiler to be smart enough to optmize such case for trivial types?

[stephenberry]

@20162026, I fixed an issue with pop_back removing the wrong element, and I fixed some use of inplace_vector<T, 0>. After going through it again I think it is in a good place, and it really is mainly existing to test the concept usage in the rest of Glaze. Do you think it's in a good place to merge?

[20162026]

Do you think it's in a good place to merge?

I will redo concepts for inplace_vector detection, as freestanding inplace_vector might not fullfill current vector_like concept.

[20162026]

CI failed becouse security.ubuntu.com is dead xd, maybe try rerunning them when it is back up....

other than that, guess Im done with the changes for now

[stephenberry]

@20162026, CI passed.

[20162026]

hi @stephenberry, don't want to rush you or sound rude, but what is the state of this PR? would you like to see some changes or is it ok as is?

[stephenberry]

I think it is in a good place. If you agree, I'll merge it in.

[20162026]

ok, you can merge it