Possible way to achieve lazy loading with const objects

[Steven Schveighoffer]

On Thu, 29 Sep 2011 14:45:13 -0400, Jonathan M Davis <jmdavisProg at 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