Drop varray implementation in favor of Boost.Container static_vector.#1458
Drop varray implementation in favor of Boost.Container static_vector.#1458tinko92 wants to merge 1 commit intoboostorg:developfrom
Conversation
308b053 to
951e9fe
Compare
|
|
||
| #include <iterator> | ||
|
|
||
| #include <boost/geometry/index/detail/assert.hpp> |
There was a problem hiding this comment.
Not directly related to this change, but this is necessary to fix a CI failure with this change, probably due to relying on indirectly importing this for the BOOST_GEOMETRY_INDEX_ASSERT macro through some removed header.
| test-suite boost-geometry-index-detail | ||
| : | ||
| [ run minmax_heap.cpp ] | ||
| [ run varray_old.cpp ] |
There was a problem hiding this comment.
The rationale for dropping these tests is that testing static_vector is done upstream in Boost.Container.
|
|
||
| public: | ||
| typedef index::detail::varray | ||
| using nodes_container_type = boost::container::static_vector |
There was a problem hiding this comment.
Pretty nice, removing the whole varray!
It is nowhere part of our public interface?
There was a problem hiding this comment.
As far as I can see, it is not.
- The files and classes are in detail folders and namespaces respectively.
- The only mention I see in the documentation is the detail header listing and the credit to Andrew Hundt.
- The serialization test (patched because it doesn't currently build due to deprecation of the "boost/timer.h" header file) in index examples runs with and without the patch for me, and when patched to load only, it seems to be able to load from the archive created by the version from current develop, so it does not seem to break serialization (when done as in this example). Side note: Do we want a stable binary serialization format for rtree in a header only library? If so, we may want to move this from an experimental example into a test.
There was a problem hiding this comment.
OK Clear, thanks. Yes, I agree, it is most probably not.
We should anyway add a note in the release notes for this larger change (BTW, that applies for my both PR's too, though smaller).
I'm fine with my approval but curious to @vissarion 's insights.
About binary serialization - not sure - we could open a "discussion" about it.
There was a problem hiding this comment.
Only used in varray - so fine to drop indeed
|
@tinko92 can you merge it? |
This PR proposes to drop the varray implementation in favour of Boost.Container static_vector, and Boost.Container vector in favour of std::vector. From my understanding static_vector and varray share a common ancestry. This would drop several tests from the regular runs and more than 4000 lines to maintain.
I noticed recent increased activity and optimizations in Boost.Container and retested varray vs static_vector with the builtin benchmark.cpp from the index/examples directory and Boost.Container checked out to the most recent develop.
Build for the release variation:
b2 cxxflags="-std=c++20 -O3 -DNDEBUG" variant=releaseDifference in measurements (Apple M5, Clang21):
The difference seems none to negligible and Boost.Container is actively maintained. Switching to this could be a step in the upgrade path to
std::inplace_vectoronce Boost.Geometry switches to C++26. Unfortunately I couldn't test inplace_vector yet, since it's not yet implemented in the STL of clang 21 (with the beman implementation I get 0.175794, 0.193613, 0.0790506 respectively, though, so the spec may allow implementations that remain both drop-in-compatible for our use case and faster).