• BobR (3/3) Apr 02 2010 When are anonymous enums preferred over named enums? Maybe they are in
• dsimcha (4/7) Apr 02 2010 IMHO anonymous enums are useful just to save typing. When the name of t...
• strtr (3/7) Apr 02 2010 I use them encapsulated within a struct to make small ranged named types...
• Mike Parker (6/11) Apr 03 2010 I use them to create D bindings to C libraries. They are useful for
• bearophile (10/11) Apr 03 2010 This is interesting. How much size differences do you see?
• Mike Parker (18/23) Apr 03 2010 I haven't actually had occasion to replace any named enums with

"BobR" <brhodes simple.access.com> writes:

When are anonymous enums preferred over named enums? Maybe they are in 
the language for historical reasons? Or are they truly useful enough to 
warrant having a 2 kinds of enums? 

dsimcha <dsimcha yahoo.com> writes:

== Quote from BobR (brhodes simple.access.com)'s article
 When are anonymous enums preferred over named enums? Maybe they are in
 the language for historical reasons? Or are they truly useful enough to
 warrant having a 2 kinds of enums?

IMHO anonymous enums are useful just to save typing.  When the name of the enum
is
unique and self-explanatory enough, I don't want the verbosity of putting it in
its own namespace.

strtr <strtr spam.com> writes:

BobR Wrote:

 When are anonymous enums preferred over named enums? Maybe they are in 
 the language for historical reasons? Or are they truly useful enough to 
 warrant having a 2 kinds of enums? 
 

I use them encapsulated within a struct to make small ranged named types.
StructName.POSSIBLE_VALUE

Mike Parker <aldacron gmail.com> writes:

BobR wrote:
 When are anonymous enums preferred over named enums? Maybe they are in 
 the language for historical reasons? Or are they truly useful enough to 
 warrant having a 2 kinds of enums? 
 
 

I use them to create D bindings to C libraries. They are useful for 
translating both C enums and #defines. Plus, if porting C++ code they 
make a good tool for translating global constants. Also, and this is a 
big one for me, anonymous enums generate no TypeInfo, which can save a 
lot of space in the binary over named enums.

bearophile <bearophileHUGS lycos.com> writes:

Mike Parker:

Also, and this is a big one for me, anonymous enums generate no TypeInfo, which
can save a lot of space in the binary over named enums.<

This is interesting. How much size differences do you see?

LDC compiler seems designed for practical usage, it has:
pragma(no_typeinfo)
You can use this pragma to stop typeinfo from being implicitly generated for a
declaration. 

There is this too (but I think it's not implemented yet):
pragma(no_moduleinfo)

Similar pragmas can be added to dmd too.

Bye,
bearophile

Mike Parker <aldacron gmail.com> writes:

bearophile wrote:
 Mike Parker:
 
 Also, and this is a big one for me, anonymous enums generate no TypeInfo,
which can save a lot of space in the binary over named enums.<

 
 This is interesting. How much size differences do you see?

I haven't actually had occasion to replace any named enums with 
anonymous ones in my own projects, but I recall this being an issue with 
Tango. But what I did in Derelict some time ago, was to replace hundreds 
of constant values with anonymous enums (another issue first highlighted 
by Tango) and got a tremendous savings in binary size, particularly in 
DerelictGL.

I just did a couple of minor tests to see how things stand now with both 
D1 and D2. In one file (1) I made around 430 const declarations. Another 
(2) replaced them all with a single, anonymous enum. In a third (3), I 
divided the anonymous enum into 25 named ones.

With both DMD 1.056 and DMD 2.042, (2) was the smallest and (1) the 
largest, but the difference is really negligible - around 1% with D1 and 
less than that with D2. While (3) is larger than (2), it's less than 
half a percent difference.

So either this doesn't hold true anymore or the scale isn't large 
enough. But it *was* an issue once upon a time. So I suppose that line 
can be stricken from the record.