Const template

[kris]

Lionello Lunesu wrote:
> Bruno Medeiros wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> Frits van Bommel wrote:
>>>
>>>> You didn't respond to my paragraph on classes though:
>>>>
>>>> Frits van Bommel wrote:
>>>>  > I also don't see a way this can work for classes (in general). 
>>>> There's
>>>>  > no way to limit a non-final method to non-mutating operations 
>>>> that I'm
>>>>  > aware of, so it could easily be circumvented by subclassing. Even 
>>>> though
>>>>  > that would only allow direct access to non-private fields, 
>>>> mutating base
>>>>  > class methods could still be called for the rest (if available). 
>>>> So then
>>>>  > the only way to get a const version of a class would be if the class
>>>>  > doesn't allow mutations anyway (like java's String). Which leaves us
>>>>  > right back where we started :(.
>>>>  >
>>>>  > And I don't think a 'const' implementation should work for 
>>>> structs and
>>>>  > not for classes...
>>>
>>>
>>> I did when I wrote:
>>>
>>>  >> That is correct. Interface functions, nonfinal methods, and
>>>  >> declared-only functions must be annotated manually.
>>>
>>> I meant - yes, you are right.
>>>
>>> Today, Walter and myself have come with a semantics for const (as in, 
>>> "read-only view" that) seems to be a good starting point. The details 
>>> are yet to be ironed out, but here's the basic plot:
>>>
>>
>> So the keyword for the "read-only view" will be 'const' too? It will 
>> share space with the 'const' as in "compile time constant" ?
> 
> 
> 'const' is not always a compile time constant. A const in function or in 
> a class can have a different value for each call/instance. Don't ask me 
> why.
> 
> 
> L.


const int also takes space in an executable. It apparenltly becomes a 
true 4-byte instance, not a compile-time constant. Though, why anyone 
would *expect* to take the address of a constant is completely beyond my 
comprehension.

No big deal, huh? Then consider the avalanche of constants in a full 
Win32 API