Logical const

[Peter Alexander]

On 21/11/10 3:32 AM, Jordi wrote:
> On 11/21/2010 02:43 AM, Michel Fortin wrote:
>> On 2010-11-20 09:21:04 -0500, Peter Alexander
>> <peter.alexander.au at gmail.com> said:
>>
>>> D does not support logical const due to the weak guarantees that it
>>> provides.
>>>
>>> So, without logical const, how are D users supposed to provide lazy
>>> evaluation and memoization in their interfaces, given that the
>>> interface should *seem* const, e.g.
>>>
>>> class Matrix
>>> {
>>> double getDeterminant() const { /* expensive calculation */ }
>>> }
>>>
>>> If it turns out that getDeterminant is called often with the raw
>>> matrix data remaining unchanged, how can we add caching to this class
>>> without rewriting the const-ness of all code that touches it?
>>
>> Using a static associative array as a cache will work:
>>
>> class Matrix
>> {
>> double getDeterminant() const
>> {
>> static double[const(Matrix)] cache;
>> if (auto resultptr = (this in cache))
>> return *resultptr;
>>
>> auto result = /* expensive calculation */;
>> cache[this] = result;
>> return result;
>> }
>> }
>>
>> and it'll continue to work even if you pass an immutable Matrix to
>> different threads (each thread has its own cache). If you don't pass
>> immutable Matrixes across threads, then you don't gain anything by
>> making the function const.
>>
>> The main reason D has const is to facilitate the usage of immutable. If
>> you don't use immutable for a given type you generally shouldn't bother
>> with const either.
>>
>> But in any case, you always can cast away const if you really need to,
>> just be sure of what you're doing. For instance, doing this breaks
>> thread-safety for immutable Matrixes:
>>
>> auto mutableThis = cast(Matrix)this;
>> mutableThis.cachedDeterminant = /* expensive calculation */;
>>
>>
>
> I am also interested in what is the D way of doing this. The associative
> array approach is not suitable for the case of 4x4 matrices in a 3D
> application where you can have thousonds of them.
>
> At some point, the associative array lookup will be more expensive than
> the actual calculation.
>
> j.

I'm a little worried by the lack of replies. I'm beginning to get the 
feeling that the D way of doing this is to rewrite the const-ness of 
your program :-(

I guess I'll just stick to not using const for now until this is resolved.