On 05/14/2012 09:18 PM, deadalnix wrote:
Le 14/05/2012 04:47, Jonathan M Davis a écrit :
They can be in almost all cases. The problem is the folks who want to
have
caching and/or lazy initiailization in their classes/structs. You
can't cache
the result of any of those functions (toHash being the main target for
it) if
they're const and pure except in overloads which _aren't_ const,
making those
functions more expensive in comparison to what they could be if they
weren't
required to be const. And lazy initialization becomes almost impossible,
because if the member variables needed in those functions haven't been
initialized yet when they're called, then you _can't_ initialize them. If
getting the value that it _would_ be without actually initializing the
member
variable works, then you can do that if it hasn't been initialized,
but if you
can't do that (e.g. the variable _must_ be set only once), then you're
screwed. And regardless of whether you can make it work with const, it
_will_
be less efficient.
Lazy initialization is more a problem than a solution when it comes to
multithreading.
How to solve the problem of representation of infinite data structures
otherwise?
And I'm afraid it is the future.
Sharing mutable data frivolously is likely not the future. I guess that
usually every thread will have its own cache.
BTW, nothing prevent to define toString an non const and another as
const. The const one cannot cache the result, but certainly can read it.
And every method that is aware of the non const version will use it.
This whole thing is overinflated. This isn't a problem. I'm pretty sure
that most code that will broke was actually already a bad idea in the
first place.
That is a rather optimistic assumption. And even if it is true for
'most' code, that is not enough imho.
