Why are all the Property component get functions const? Like: const double getValue() const
I have a mix-in class that keeps a last and current state XmlElement to give to an undoable action when the properties are adjusted. In the get functions, I try to update those values - but the const makes me jump through hoops. Is there something going on that makes this necessary, or else please could it be changed?
Bruce
You shouldn’t be updating anything in get() methods! That’s why they’re const. If you have a const property object you’d expect to be able to get some values from it without having to const_cast it.
If you’ve got a member that needs to change during a const call, use the mutable keyword, but it’s a warning that something’s probably a bit wrong with your design!
Well, it was a warning sign. I do get the idea. But I was rather hoping that you were being cautious.
I did the mutable thing already, and since they’re attributes brought in from a mix-in class for this reason, it seems OK. I don’t see where else I would do this, unless I store it all somewhere else. The general idea is that each property can easily rustle up it’s new state and ‘old’ state in XML to send around.
Think of it as buffering the value for use when we change. I suppose I could do some fake get before I do a set, but this seems OK to me.
See any specific difficulties?
Bruce
I see what you mean, but a get() method feels like the wrong place to do that kind of work. Nothing wrong with using a mutable though, I guess it’s the kind of situation that they invented it for.
I use mutable members when the “spirit” of the class is indeed const, but I’d like to use a spot of lazy initialisation.
Same here.
I once had a very bizarre argument with a another coder (who by and large is way ahead of my skillset) who adamantly insisted that mutable was a sin comparable to goto. I tried repeatedly to explain that to me, code that can’t buffer up heavy duty calculations until they are actually needed is pretty damn evil too, but we’d pretty much hit stalemate from the moment the argument started.
I still can’t understand why some people get so freaked out by mutable. Sure it allows idiots to do utterly busted stuff, but so do pointers, recursion, and all manner of other things that are considered essential to the c++ language.
Oh, he was pretty anti multiple inheritance too. 
Same here.
I once had a very bizarre argument with a another coder (who by and large is way ahead of my skillset) who adamantly insisted that mutable was a sin comparable to goto. I tried repeatedly to explain that to me, code that can’t buffer up heavy duty calculations until they are actually needed is pretty damn evil too, but we’d pretty much hit stalemate from the moment the argument started.
I still can’t understand why some people get so freaked out by mutable. Sure it allows idiots to do utterly busted stuff, but so do pointers, recursion, and all manner of other things that are considered essential to the c++ language.
Oh, he was pretty anti multiple inheritance too. :)[/quote]
The book, “C++ Common Knowledge” by Stephen C. Dewhurst has an excellent article on this. Great book. I thought mutable was evil too until I read this. Felt quite chuffed when I used one in a viable situation, after I had my “const epiphany”. All C++ coders get that right?
Const is one of those things that feels like it’s essential, but I’ve taken the luxury of mostly ignoring to this point, seeing as I’m 90% a solo coder.
It seems to imply that there’s some shennanigans going on that needs to be protected against.
Based on this discussion, I would have to say that multiple inheritance confuses things somewhat. Although Jules’ original class needed this function to be const, my co-superclass needs to modify stuff - but I don’t want to re-invent the wheel, in this case the ‘refreshAll’ system.
Works like a champ, BTW. Bit heavy on the XML parsing and object creation, but it allows all my ‘in between’ code to go easy on members and use XML as the data.
Bruce
