DataPointsFilters, OutlierFilters, Transformations, and TransformationCheckers structs inherit from a class without virtual destructor

[YoshuaNava]

The structs mentioned in the description inherit directly from std::vector, an STL container. For example:

https://github.com/ethz-asl/libpointmatcher/blob/master/pointmatcher/PointMatcher.h#L422

The above can lead to undefined behavior, as the STL containers don't have virtual destructors. Therefore, any collection of polymorphic objects from those types could have issues getting destroyed.

References:

• https://quuxplusone.github.io/blog/2018/12/11/dont-inherit-from-std-types/
• https://stackoverflow.com/questions/6806173/subclass-inherit-standard-containers/7110262#7110262
• https://www.researchgate.net/post/I-really-want-to-understand-if-there-is-any-reason-why-one-should-not-inherit-from-the-stl-vector-class-in-c/5304df29d3df3edb158b45f3/citation/download

[YoshuaNava]

An example of how this could impact usage of the library is when people inherit from one of the containers cited above, as DataPointsFilters/Gestalt. This filter is stateless (saves no state, only parameters): https://github.com/ethz-asl/libpointmatcher/blob/master/pointmatcher/DataPointsFilters/Gestalt.h#L94

When the filter is created, used and tore down, it is undefined how the parameters are destructed. If we were to implement a filter that uses history, this could result in a memory leak in the worst case.

[pomerlef]

Interesting reading this morning. What would be your solution here?