[Nicogene]

It removes boost as dependency, since it was only used for boost::circular_buffer I asked to the AI to write a custom circular buffer class, it verified that behaves the same

In the far 2020 was crazy to implement your own CircularBuffer and was more convenient to add boost as dependency. In 2026 thanks to the AI the burden is more maintain an external dependency that write your own tool

[Nicogene]

Important

This is a API/ABI breaking change, the migration is explained in the readme
cc @traversaro @S-Dafarra @GiulioRomualdi

I don't know why I cannot set everyone as reviewer, but fill free to add your comments/review

[S-Dafarra]

On the performance side, did you run any benchmark?

[S-Dafarra]

Same as above

[traversaro]

Important

This is a API/ABI breaking change, the migration is explained in the readme cc @traversaro @S-Dafarra @GiulioRomualdi

I don't know why I cannot set everyone as reviewer, but fill free to add your comments/review

From the conda-forge package level it is assume that there could be ABI changes in every new patch release, see https://github.com/conda-forge/librobometry-feedstock/blob/f17bd7715ee4ff62aa86e01e55071f18b7af3756/recipe/recipe.yaml#L43 , so we are fine. From the API point of view, I think it make sense to bump the major or at least the minor versions.

[Nicogene]

I asked to Astra to perform some benchmarks, and we found several bottlenecks and inefficiencies

I committed all the reports/code used for the benchmark, we can get rid of it before merging

It optimized storage allocation and element transfers based on the benchmark findings, using uninitialized storage and bulk move/copy operations.

Capacity changes vs Boost 1.83, GCC 13.3, C++17, -O3 -DNDEBUG. Times are microseconds per set_capacity() call:

Workload	Capacity change	Boost	Robometry
Grow 1024 scalar records	1024 → 2048	7.02	6.05
Grow 1024 vector records	1024 → 2048	4.85	4.46
Grow an empty Record buffer	0 → 100000	1.80	1.83

Vector records contain 32 doubles in std::any. Across actual capacity changes, the largest Robometry/Boost ratio was 1.13x with GCC 13 and 1.15x with GCC 11 (unchanged-capacity no-ops excluded). Steady-state ratios reached 1.66x for vector-record clear/refill with GCC 13.

Storage: both containers use 24 bytes per Record slot on this platform, with one destination allocation per nonzero capacity change and no extra payload allocations during Record relocation.

These are local WSL2/Ubuntu 24.04 medians from nine batches with fixed CPU affinity. Windows/MSVC was not measured.

Validation: 22/22 tests pass with GCC 11, GCC 13 and ASan/UBSan/LSan. Full results and reproduction commands: benchmarks/README.md and benchmarks/CAPACITY.md.