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

[deadalnix]

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. And I'm afraid it is the future.

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.