Const template

Andrei Alexandrescu (See Website For Email) SeeWebsiteForEmail at erdani.org
Tue Jan 23 12:18:41 PST 2007


Frits van Bommel wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Frits van Bommel wrote:
>>> But as I mentioned, there will only be const references to const 
>>> instances, so that would mean const objects couldn't be explicitly 
>>> deleted.
>>> And there are people who prefer or need to work with GC off. This 
>>> limitation would deny them the use of const objects (unless they like 
>>> memory leaks ;) ).
>>
>> I disagree. If you want to disable the GC, that doesn't mean you can't 
>> use const. You use a private non-const reference for ownership 
>> purposes, and you use a const reference for publishing purposes:
> 
> <pedantic> I said const *objects*, not const references. </pedantic>

This is actually a great point. In the case of classes, is const a 
property of the value, or a property of the reference through which the 
value is accessed?

This philosophical-sounding question leads actually to radically 
different implementations. If you associate constness with the value, 
then you have true immutable values. This was, at a point in the history 
of humankind, Walter's opinion of a good starting point for talking 
about const: true ROMable values. However, that approach is too rigid to 
be useful: too rarely you have truly immutable data, but most often you 
want to make sure that certain parts of a system *think* data is immutable.

A relaxation of that concept therefore is to associate constness with 
the reference through which the value is accessed. Then you have much 
more flexibility in that you can have some mutable object, pass it to a 
function through a const handle (thus knowing that that function can 
never change it), and then continue enjoying mutable access to that object.

The downside of this relaxation is that aliasing might stick its nose. 
My conjecture is that in the vast majority of cases it can be trivially 
proved (by the compiler) that no aliased access can affect const data. 
And even in the cases where the compiler must generates conservative 
code (as it does today in 100% of the cases), the benefit to the 
programmer still justifies this more relaxed view of immutability.

So: class objects are never const. Const references only restrict 
access, not the nature of bits on the heap.


Andrei



More information about the Digitalmars-d mailing list