On 11/07/2012 17:49, Timon Gehr wrote:
On 07/11/2012 05:27 PM, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
I was a long-time proponent of this. It's less exciting than it may
seem actually.
(a) Classes that work with const just fine incur one extra virtual
call. I think this can be avoided by having the compiler plant the
same pointer for the const and non-const version in the vtable.
(b) Classes that can't do as little as one of these four operations
without mutating the object are completely excluded from the
immutability system, even if they'd otherwise benefit from it. Even
those that don't "care" they need to actively _work_ on not caring,
which doesn't sit well.
So I don't see this as a viable solution to people who are fine with
const, but would like to use e.g. some lazy computation.
Andrei
This solution is not for allowing people to use lazy computation in
their const overrides, it's for allowing people to still use opEquals,
toString etc. even if their implementations cannot and should not be
const.
In this case, they have function that does something else than compare
test for equality, etc . . . The overload make no sense here in the
first place, and the fact that const break such thing isn't a problem.
This is the other way around, the fact that const break such a practice
is good.
I think this posts roots in a misunderstanding of 'cannot and should not
be const'.
If it cannot and should not be const, it isn't a comparison or an
equality test, it is another operation altogether that is performed.
