Towards #676
This changes nothing pertaining to the implementation. It only adds testing.
Some of it is implementation-specific, but towards the ends of performance checks.
It needs to hold an arbitrary number of entries, because we don't know the rate at which we will get data.
The items needs to be in sorted order by timestamp, from the newest entry to the oldest.
New items need to be inserted into arbitrary positions, as timestamps may come in out-of-order.
Duplicates shouldn't be allowed.
Old items need to be pruned out.
To answer them:
There appears to be no limit on size. Not sure how to test this in a bounded fashion.
This was not tested. Now explicitly tested via ImplSortedDescendingUniqueEntries
This was not tested. Now explicitly tested via ImplSortedDescendingUniqueEntries
This was already tested, but is also explicitly tested via ImplSortedDescendingUniqueEntries
This was not tested (I believe). Now explicitly tested via ImplSortedDescendingUniqueEntriesThis is an automatic backport of pull request #678 done by Mergify.
Towards #676 This changes nothing pertaining to the implementation. It only adds testing. Some of it is implementation-specific, but towards the ends of performance checks.
From https://github.com/ros2/geometry2/issues/676#issuecomment-2102512107
To answer them:
ImplSortedDescendingUniqueEntries
ImplSortedDescendingUniqueEntries
ImplSortedDescendingUniqueEntries
ImplSortedDescendingUniqueEntries
This is an automatic backport of pull request #678 done by Mergify.