Why struct opEquals must be const?

[so]

If you want to invoke a generic function that calls some methods of your  
input, most of the time you need to be sure these methods are  
"const-correct", especially when your input is const.

It is both a good and bad thing.

On Sun, 17 Oct 2010 09:57:02 +0300, Nick Sabalausky <a at a.a> wrote:

> Is there a technical reason why the l- and r- values for opEquals must be
> const? If the restriction is purely for the intuitive notion that  
> there's no
> heisenstructs, then I have an example I think might be worth  
> consideration:
> lazy caching.
>
> If comparison isn't always needed and requires a potentially expensive
> computation that isn't likely needed otherwise (for example, a wrapper  
> for
> string that does case-insensitive comparisons, if it's used in a  
> situation
> that does more assigning/slicing/etc than comparing), then it may make  
> sense
> to wait until an opEquals is called, and then compute the information and
> cache it. But that requires mutating state and so can't be done in a  
> struct
> opEquals.
>
> 'Course, if there is a technical reason for the restriction, then all  
> this
> is moot.
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/