On Thu, 10 Feb 2011 03:37:58 -0500, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Thursday 10 February 2011 00:19:38 Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a member function of
Object.
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be marked
const.
(2) If it is not const, then const objects cannot be compared!
Currently, it's not const, but the problem isn't visible because of
compiler bug 5080. (Same problem applies to opCmp).
How will we break this dilemma?
Honestly, I think that opEquals should just be const. It doesn't
generally make
any sense for it not to be const anyway. And if Object's opEquals
_isn't_ const,
then const in general is screwed. opEquals, toString, opCmp, and toHash
_all_
need to be const for const and immutable classes to work in general. I
just
don't think that it's realistic to say that a programmer can totally
ignore
const if they don't want to worry about it.
But for the most part, what does it matter? So, there's a few functions
which
they have to mark as const, because that's the way that they are in
Object. That
doesn't mean that it's viral throughout their program. They can just
skip const
everywhere else.
This isn't really true. If you make opEquals const, then anything
opEquals calls must be const. Inevitably, you need to make a lot of your
object const, which then goes viral to things that object uses, etc.
On the other hand, I don't think opt-in const is that worthy a goal.
Things that are const, should be const.
-Steve
