Getting the const-correctness of Object sorted once and for all

[Timon Gehr]

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.