On Thu, 29 Sep 2011 14:45:13 -0400, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Thursday, September 29, 2011 10:50 Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander
> The comparison may involve comparing a sub-object that is lazily
> created. It could also involve computing a cached perfect hash for
> faster comparison, requiring memoization.
Neither of these are required for opEquals to work. They are
optimizations.
True, but by making opEquals const and only const, you're disallowing
such
optimzations. It becomes impossible for someone to do any kind of lazy
loading
at all. So, in principle, I definitely think that opEquals should be
const,
and practically-speaking it _needs_ to be const for const to work
properly,
but if we make it _only_ const, then we're disallowing some performance-
related stuff that some people care a lot about.
Not at all. You are not forced to use obj == obj to do comparisons.
Also, if we force opEquals to
be const, then those classes that just _can't_ be const and work properly
(e.g. those that _require_ logical const to even work - like if they
have a
mutex) won't be usable at all. So, making it both seems to be the only
real
option.
Mutexes are usable within const functions. They are *always* logically
const. It's one of the reasons I think a subset of logical const works
well, even if we don't have full-blown support. I still feel there is a
logical const solution out there which gets enough of the way there to be
useful, but makes circumventing immutable impossible or highly unlikely.
Though come to think of it, since you _still_ can't have lazy loading
when a
const opEquals even _exists_, you're either still going to have to
forgoe lazy
loading, make the const opEquals throw, or get nasty bugs when the non-
overridden base class version of opEquals gets thrown. So, this could be
even
worse than we were thinking...
I'm not quite sure what the correct solution is then. By having both, we
allow
for both paradigms but make the use of const opEquals potentially buggy
in the
cases where someone insists on doing lazy loading. But if we insist on
only
having the const opEquals, then some folks are going to get an
unavoidable
performance hit in their programs. If caching is the only issue, then
it's a
non-issue, because the const versions just become less efficient in the
cases
where the value is dirty, but if the state of the function actually
needs to
be changed for opEquals to work (e.g. lazy loading or internal mutexes),
then
we're going to have cases where the const opEquals can't possibly work
correctly.
I think the caching/lazy loading *specifically for opEquals* has been
blown way out of proportion. I don't think I've ever written one which
requires caching to be efficient.
-Steve
