Frank Naumann wrote:
Hello!From the user's perspective, if a method may be reasonably called upon a constant object, it should be declared const. Whether it actually changes the internal state is irrelevant; if it appears that it does not, then const it should be. That's what mutable is for, as has been mentioned.Then I don't see the difference against making all objects and methods constant and declare all member data mutable.But to be honest, I never really understand for what mutable was introduced. I read the chapter about mutable in Stroustroup several times with getting the point.
Then it's not surprising that you haven't understood the point Murray is attempting to make. Unfortunately I don't think I'm really qualified to explain it. It's clear enough what mutable actually does, I hope, but the issue of what it's actually *for* is more difficult.
It's not good style, but had your code been written for gtkmm 2.4 to start with, you would no doubt have developed a more elegant solution.Maybe. But for dynamically calulated content I don't see a solution yet. Maybe there is a better solution for my problem now (I render directly from an internal and rather complex data structure the treeview; it's the wanted behaviour to recalculate the content every time a redraw is done; this was elegant to implement with a own specialized CellRenderer).
I would be surprised if the recomputation you are doing requires a change in the underlying data or the fundamental state of the CellRenderer; therefore you should be able to do it inside a const method without a great deal of difficulty, perhaps with the help of a few mutable data members (perhaps for result caching where appropriate).
From within a const method you can't call any non-const methods on the same object (unless you start using const_cast<>, which isn't to be advised if you can avoid it), so you'd have to look at your helper methods and determine if they could also be declared as const.
It seems a good rule of API design to write methods as const whenever you possibly can. This provides a clear and guarenteed interface to the user, helping them to write code that doesn't have unexpected side effects. That might be the Haskell programmer in me speaking.
I'm with Murray on it being right to have get_size_vfunc be const though.Then my question, why is get_size_vfunc const? What's the difference compared to render_vfunc for example?
I can't answer that question, as I had no input on the design of the API there. I would have expected render_vfunc to be const, but it may operate in a way which surprises me and forces it to be non-const.