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. 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. 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. This is ugly. - Jonathan M Davis
