On 11/07/2012 18:30, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
[...]
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.
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. But being forced to use const means I can't
cache anything. And this isn't just about caching; if my tree is
partially stored in the database, and I have a DB connection object in
my tree class, then I can't use opEquals because I can't modify the DB
state (which is impractical if I have to actually use it to make DB
queries -- the DB engine may have to cache DB pages, etc.). Any
abstraction of opEquals beyond the bitwise level cannot be implemented.
Either the structure is mutable, and you have to recompute anyway, or
the structure is trully const and thing can be computed up-front.
