Resolve "Work on const / non-const in wolf base classes"

Closes #184 (closed)

added External API update To Do (release) labels

added 29 commits

• 66ce83e5...810c53ab - 29 commits from branch devel

Compare with previous version

added 7 commits

• 24320581 - SensorBase const qualifier changes.
• 9932617d - ProcessorBase const qualifier changes
• fe2dfdf7 - FactorBase const qualifier changes
• 2c4a551e - FeatureBase const qualifier changes
• a92fdfcf - FrameBase const qualifier changes
• 82a774b5 - TrajectoryBase const qualifier changes
• a124bc6b - LandmarkBase const qualifier changes

Compare with previous version

added 111 commits

• a124bc6b...38cd6a41 - 110 commits from branch devel
• e5bc2c42 - Merge branch 'devel' into 184-work-on-const-non-const-in-wolf-base-classes

Compare with previous version

Just FYI: I merged a few related work that I pushed to devel, regarding many const. This branch is now more close to devel.

added 1 commit

• 364e1ec0 - Add const to delta operations

Compare with previous version

added 1 commit

• 9f55add5 - Some more const

Compare with previous version

added 1 commit

• b8d19c9c - Update processor_odom_3D.cpp

Compare with previous version

added 1 commit

• 0da54d2b - Add const to track matrix methods

Compare with previous version

added 2 commits

• e83c49af - 1 commit from branch devel
• 329e9269 - Merge branch 'devel' into '184-work-on-const-non-const-in-wolf-base-classes'

Compare with previous version

closed

reopened

unmarked as a Work In Progress

enabled an automatic merge when the pipeline for 329e9269 succeeds

@jcasals I am merging this today.

there's more work to do here, in defining XxxCPtr instead of XxxPtr, but this I find it difficult by now.

The branch so far implements most of the const for class methods in core, and then appropriate MR fixes are ready for all plugins -- except loopclosure_vision which I did not touch.

canceled the automatic merge

I mean, I will leave the branch open, and I will merge manually, not by accepting the MR. However, it is possible that the issue and the MR disappear from GitLab if I just merge into devel...

Seems good . I think that this MR will need a bit of time and refinement, so perhaps this const/non-const is something that we should keep in mind but not necessarily have it as a merge request, because it seems to me that this task is so big that the MR will be open indefinitely, which is a bit odd maybe?

Yes... true. So I accept the MR then!

merged