Manifest constants: why enum instead of invariant?

Don nospam at nospam.com.au
Mon Apr 28 00:06:02 PDT 2008


Bill Baxter wrote:
> Bruno Medeiros wrote:
>> Picking up and idea which had crossed my mind, and that Oskar Linde 
>> briefly mentioned on the const debacle thread 
>> (news://news.digitalmars.com:119/fsirc9$2hll$1@digitalmars.com):
>>
>> Why do we need enum instead of invariant to declare manifest constants?
>>
>> (I have the feeling that this has been discussed before in the 
>> manifest constants debate but I can't remember it nor find it)
>>
>> An invariant variable offers all the power than enum does for manifest 
>> constants. The only difference of enum's manifest constants is that 
>> they are not an lvalue (their address cannot be taken). But that's a 
>> *restriction*, it's not a useful property.
>>
>> The only possible advantage I see is that of optimization: manifest 
>> constants do not take up space. But that *hardly* seems significant: 
>> manifest constants are usually numeric, and thus occupy about 2-4 
>> bytes each. Even if they are many, in total they are not going to 
>> occupy that much space. A string literal can easily occupy as much 
>> space as several manifest constants, and they are likely going to be 
>> many string literals abound.
>>
> 
> The space *is* a significant problem apparently.  There have been many 
> complaints about the size added to an exe simply by linking in early 
> versions of the Windows headers because of all the constants they define.
> 
> But I suppose you could also look at that and say "we need to fix the 
> linker & optimizer" instead of "we need to fix the language".

Indeed. Manifest constants are required primarily as a workaround for 
the linker; the linker should be able to discard them. In practice, most 
of the time, invariant will probably be used anyway. I think much of the 
furore about using enum for constants fails to recognise how minor the 
feature is.

IMHO, the unfortunate thing about using enum for manifest constants is 
that it destroys any chance of better enums.



More information about the Digitalmars-d mailing list