Frank Naumann wrote:
Hello!But another thing about CellRenderer. Is there any reason whyget_size_vfunc is now 'const' ? This is IMHO a very bad idea as everybodywho write it's own CellRenderer is very limited (especially if you dynamically calculate the cell content).I don't understand. If the method should not change the instance, then the method should be const.Yes, that is right.Do you think that this method should change the instance?You know before that other developer want todo? Why you assume that get_size_vfunc don't change the instance? If I see this right Gtk::CellRenderer is supposed to be a base class for self defined renderers. So you can't know before how what they like todo.
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.
If you need to change member data without really changing the instance, then you need to use the mutable keyword. Const is whatever you define it to mean.Adding tons of mutable keywords to most of my own instance data just to be able to add the 'const' qualifier to lot of other private methods (that are called by get_size_vfunc) is not a good style or solution. At least I don't see a reason why this is good or better only to have get_size_vfunc as const method.
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. It's the change from non-const to const that seems to have caused the most significant problem.
If you really need a workaround, use const_cast<> to get a pointer to the non-const instance of your object, and then call your other methods on that. Not particularly pleasant, but rather something of a stopgap for an unfortunate design.
I'm with Murray on it being right to have get_size_vfunc be const though. Asking an object what its size is shouldn't change anything else I can see about the object, and as far as I'm concerned that means the method should be const. Even if you're doing a lot of computation internally to provide the return value. I appreciate that you don't want to declare half your data members mutable, but this isn't a problem with gtkmm 2.4, it's more a problem with gtkmm 2.2, which perhaps should have been this way from the start.