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 <[email protected]> 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/
