PoseGraphInterface can mostly be const

[gaschler]

Currently, all methods in PoseGraphInterface are not const, even though most of them can be.
I think the reason was that they require a read mutex, but semantically, they are const.

[cschuet]

Making the mutex mutable is not forbidden by the C++ style guide

[SirVer]

That is a philosophical decision. We decided way back that in Cartographer, const should mean the same for the compiler and us, so we never used mutable ever. mutable is also a slippery slope, diluting the possibility to correctly reason about class state from the outside. I think the Chromium project landed on the other side, using mutable all over the place and trying to express with const semantic constness.

Further reading, though a bit outdated:

• https://www.amazon.de/More-Effective-Addison-Wesley-Professional-Computing-ebook/dp/B004VSMDNY

[ojura]

I stumbled into this talk, which I found interesting. It argues that the meaning of const and mutable changed profoundly in C++11.
https://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank

[sebastianklose]

@ojura - this is a nice talk, thanks for sharing.

For those who can't spare the time to watch it, the summary is that in C+11 the meaning of const and mutable has change away from "logically const" to "thread-safe" (bitwise const or internally synchronized). Meaning, declaring a synchronized object (like a mutex) mutable is concise and actually desired.

That being said, I will move forward with changing Cartographer classes to reflect this, as it also makes other classes using these object more sane in terms of const-ness.