## D - super duper enumerations

• D Man (27/27) Aug 16 2001 I currently use many enumerated values in my code. I find myself settin...
• Walter (3/30) Aug 17 2001 2,
• Chris Friesen (18/35) Aug 17 2001 This one is kind of wierd, but I can see how it could be useful occasion...
• D Man (30/35) Aug 17 2001 version
• D Man (3/5) Aug 17 2001 mode.size() should be mode.count(), sorry.
• Chris Friesen (9/19) Aug 17 2001 Ah, okay. I hadn't considered that type of usage. Yes, it could make t...
• Sheldon Simms (16/37) Aug 17 2001 Is that supposed to be a valid reason to introduce dangerous features
• Chris Friesen (9/20) Aug 17 2001 I definately like this better. Being able to loop over enums directly w...
• D Man (4/24) Aug 17 2001 I really like this!
• Anthony Steele (8/12) Sep 09 2001 That's just like pascal - on any eum type, the low() and high() built-in
• John Carney (6/33) Aug 17 2001 All very good thoughts IMHO :)
• Kevin Quick (21/21) Aug 21 2001 Another issue to consider is multi-bit values versus unique values.
• Walter (13/38) Dec 22 2001 =
• Pavel Minayev (17/26) Dec 22 2001 Still... compare the following snippets
• Walter (4/21) Dec 22 2001 You can still do the first in D.
• Anthony Steele (27/32) Sep 09 2001 these
• Anthony Steele (27/32) Sep 09 2001 these
"D Man" <clockwork austin.rr.com> writes:
```I currently use many enumerated values in my code.  I find myself setting
values for bit flags and other non-linear sets.  What do you think of these
ideas? (Syntax is for illustration only.)

1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b = 2,
c = 4, etc.
2. Previous value plus n.  enum blah { a, b + 0xf, c, d, e + 0x3}; a = 0, b
= 0xf, c = 0x10, d = 0x11, e = 0x14.
3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0 so
you can find ranges without considering the names of the enumerations or
defining the ever-present MaxVal in your enumerations.
4. Continuation of enumerations.  class A{ enum mode {input, output}; };
Class B: public A{ enum(append) mode {io, null }; };.  Useful if you add
modes via inheritance (ie, io class -- which uses multiple inheritence,
btw).  Using this would allow you to add new modes without all the
dependencies on initial statement.
5. Access enumerations as arrays.  Using #4, mode[3] in the appended
enumeration yields the value for "io."  mode[3] in the un-appended version
throws an exception.  You could remove values as well.
6. As text.  So, using #4 again, as_text(mode[0]) returns a char * to the
string "input".

If these features existed in c++, I could go home early today. *sigh*
_________________________________________________

Robert Sitton

Senior Software Engineer & Digital Holographer

clockwork austin.rr.com

"Some engineers code to live, but I live to code..."

www.zebraimaging.com www.apple.com www.nintendo.com
```
Aug 16 2001
"Walter" <walter digitalmars.com> writes:
```Wow, I never thought about enums that much! -Walter

D Man wrote in message <9liemf\$s2r\$1 digitaldaemon.com>...
I currently use many enumerated values in my code.  I find myself setting
values for bit flags and other non-linear sets.  What do you think of these
ideas? (Syntax is for illustration only.)

1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b =

2,
c = 4, etc.
2. Previous value plus n.  enum blah { a, b + 0xf, c, d, e + 0x3}; a = 0, b
= 0xf, c = 0x10, d = 0x11, e = 0x14.
3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0 so
you can find ranges without considering the names of the enumerations or
defining the ever-present MaxVal in your enumerations.
4. Continuation of enumerations.  class A{ enum mode {input, output}; };
Class B: public A{ enum(append) mode {io, null }; };.  Useful if you add
modes via inheritance (ie, io class -- which uses multiple inheritence,
btw).  Using this would allow you to add new modes without all the
dependencies on initial statement.
5. Access enumerations as arrays.  Using #4, mode[3] in the appended
enumeration yields the value for "io."  mode[3] in the un-appended version
throws an exception.  You could remove values as well.
6. As text.  So, using #4 again, as_text(mode[0]) returns a char * to the
string "input".

If these features existed in c++, I could go home early today. *sigh*
_________________________________________________

Robert Sitton

Senior Software Engineer & Digital Holographer

clockwork austin.rr.com

"Some engineers code to live, but I live to code..."

www.zebraimaging.com www.apple.com www.nintendo.com

```
Aug 17 2001
Chris Friesen <cfriesen nortelnetworks.com> writes:
```D Man wrote:

1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b = 2,
c = 4, etc.

I like this.  Very useful for flags.

2. Previous value plus n.  enum blah { a, b + 0xf, c, d, e + 0x3}; a = 0, b
= 0xf, c = 0x10, d = 0x11, e = 0x14.

This one is kind of wierd, but I can see how it could be useful occasionally.

3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0 so
you can find ranges without considering the names of the enumerations or
defining the ever-present MaxVal in your enumerations.

YES!

4. Continuation of enumerations.  class A{ enum mode {input, output}; };
Class B: public A{ enum(append) mode {io, null }; };.  Useful if you add
modes via inheritance (ie, io class -- which uses multiple inheritence,
btw).  Using this would allow you to add new modes without all the
dependencies on initial statement.

Sounds good.

5. Access enumerations as arrays.  Using #4, mode[3] in the appended
enumeration yields the value for "io."  mode[3] in the un-appended version
throws an exception.  You could remove values as well.

Hmm.  Not sure I see the point of this.  What happens if somone changes the code
and re-orders the enum?  This sounds a bit dangerous to me.

6. As text.  So, using #4 again, as_text(mode[0]) returns a char * to the
string "input".

YES!  I don't know how many times I've written switch statements like

case BLAH:
cout << "BLAH";

This would be great.

I have doubts about 5, but the others could all be very handy.

Chris

--
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen nortelnetworks.com
```
Aug 17 2001
"D Man" <clockwork austin.rr.com> writes:
```6. Need the number values in the enumerated type.  For example, count =
mode.size();

5. Access enumerations as arrays.  Using #4, mode[3] in the appended
enumeration yields the value for "io."  mode[3] in the un-appended

version
throws an exception.  You could remove values as well.

Hmm.  Not sure I see the point of this.  What happens if somone changes

the code
and re-orders the enum?  This sounds a bit dangerous to me.

Many features in c++ are potentially dangerous.  How does this virtual
method look:
void io_base::dump_modes()
{
cout << "Available Modes:\n";
for(int options = 0; options < mode.size(); ++options)
{
cout << as_text(mode[options]) << endl;
}
}

class io_base output:
Available modes:
exists

Available modes:
exists

class writer output:
Available modes:
exists
write

Available modes:
exists
write
```
Aug 17 2001
"D Man" <clockwork austin.rr.com> writes:
```mode.size() should be mode.count(), sorry.

"D Man" <clockwork austin.rr.com> wrote in message
news:9lj6oi\$1evn\$1 digitaldaemon.com...
6. Need the number values in the enumerated type.  For example, count =
mode.size();

```
Aug 17 2001
Chris Friesen <cfriesen nortelnetworks.com> writes:
```D Man wrote:

Many features in c++ are potentially dangerous.  How does this virtual
method look:
void io_base::dump_modes()
{
cout << "Available Modes:\n";
for(int options = 0; options < mode.size(); ++options)
{
cout << as_text(mode[options]) << endl;
}
}

Ah, okay.  I hadn't considered that type of usage.  Yes, it could make things
easier.

Chris

--
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen nortelnetworks.com
```
Aug 17 2001
"Sheldon Simms" <sheldon semanticedge.com> writes:
```Im Artikel <9lj6oi\$1evn\$1 digitaldaemon.com> schrieb "D Man"
<clockwork austin.rr.com>:

6. Need the number values in the enumerated type.  For example, count =
mode.size();

5. Access enumerations as arrays.  Using #4, mode[3] in the appended
enumeration yields the value for "io."  mode[3] in the un-appended

version
throws an exception.  You could remove values as well.

Hmm.  Not sure I see the point of this.  What happens if somone changes

the code
and re-orders the enum?  This sounds a bit dangerous to me.

Many features in c++ are potentially dangerous.

Is that supposed to be a valid reason to introduce dangerous features
in other languages.

How does this virtual method look:
void io_base::dump_modes()
{
cout << "Available Modes:\n";
for(int options = 0; options < mode.size(); ++options) {
cout << as_text(mode[options]) << endl;
}
}

Another option would be something like:

class io_base
{
void dump_modes()
{
printf("Available Modes:\n");
for a_mode in mode
printf(a_mode.as_text());
}
}

--
Sheldon Simms / sheldon semanticedge.com
```
Aug 17 2001
Chris Friesen <cfriesen nortelnetworks.com> writes:
```Sheldon Simms wrote:

Another option would be something like:

class io_base
{
void dump_modes()
{
printf("Available Modes:\n");
for a_mode in mode
printf(a_mode.as_text());
}
}

I definately like this better.  Being able to loop over enums directly would be
handy.

Chris

--
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen nortelnetworks.com
```
Aug 17 2001
"D Man" <clockwork austin.rr.com> writes:
```I really like this!

"Chris Friesen" <cfriesen nortelnetworks.com> wrote in message
news:3B7D56F4.9D64682C nortelnetworks.com...
Sheldon Simms wrote:

Another option would be something like:

class io_base
{
void dump_modes()
{
printf("Available Modes:\n");
for a_mode in mode
printf(a_mode.as_text());
}
}

I definately like this better.  Being able to loop over enums directly

would be
handy.

Chris

--
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen nortelnetworks.com

```
Aug 17 2001
"Anthony Steele" <asteele nospam.iafrica.com> writes:
``` 3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0

so
you can find ranges without considering the names of the enumerations or
defining the ever-present MaxVal in your enumerations.

YES!

That's just like pascal - on any eum type, the low() and high() built-in
functions will resolve at compile time to the first & last elements
respectively. Also, the suc() and pred() fns will give you next & previous
elements, which makes for loops and while loops on enums fairly trivial.

Enums are useful in pascal, and sets of enums even more so, especially for
option flags. Yes, they are implemented as bit masks, but that's a detail
you don't have to worry about.
```
Sep 09 2001
"John Carney" <john.carney pacific.net.au> writes:
```All very good thoughts IMHO :)

"D Man" <clockwork austin.rr.com> wrote in message
news:9liemf\$s2r\$1 digitaldaemon.com...
I currently use many enumerated values in my code.  I find myself setting
values for bit flags and other non-linear sets.  What do you think of

these
ideas? (Syntax is for illustration only.)

1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b =

2,
c = 4, etc.
2. Previous value plus n.  enum blah { a, b + 0xf, c, d, e + 0x3}; a = 0,

b
= 0xf, c = 0x10, d = 0x11, e = 0x14.
3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0 so
you can find ranges without considering the names of the enumerations or
defining the ever-present MaxVal in your enumerations.
4. Continuation of enumerations.  class A{ enum mode {input, output}; };
Class B: public A{ enum(append) mode {io, null }; };.  Useful if you add
modes via inheritance (ie, io class -- which uses multiple inheritence,
btw).  Using this would allow you to add new modes without all the
dependencies on initial statement.
5. Access enumerations as arrays.  Using #4, mode[3] in the appended
enumeration yields the value for "io."  mode[3] in the un-appended version
throws an exception.  You could remove values as well.
6. As text.  So, using #4 again, as_text(mode[0]) returns a char * to the
string "input".

If these features existed in c++, I could go home early today. *sigh*
_________________________________________________

Robert Sitton

Senior Software Engineer & Digital Holographer

clockwork austin.rr.com

"Some engineers code to live, but I live to code..."

www.zebraimaging.com www.apple.com www.nintendo.com

```
Aug 17 2001
Kevin Quick <kevin.quick surgient.com> writes:
```Another issue to consider is multi-bit values versus unique values.

In C enums are implemented as unique values, but D appears to take the
opposite approach.  Obviously, multi-bit values requires non-overlapping
values (vis. the enum(2) recommendation).

Perhaps enum(2) should be enum(bitmap) [hash out the syntax later] which
indicates to the compiler two things:
a) multiple values may be set simultaneously
b) values should not overlap (ergo the enum(2) behavior, even if the
values aren't uniquely specified).

enum state { Init, Open, Read, Close };

state = Init;
fd = open("foo.txt", filemode);
state = Open;
...

--
________________________________________________________________________
Kevin Quick                  Surgient Networks               Project UDI
kevin.quick surgient.com      Austin,  Texas                      Editor
+1 512 241 4801              www.surgient.com         www.projectudi.org
```
Aug 21 2001
"Walter" <walter digitalmars.com> writes:
```"> "D Man" <clockwork austin.rr.com> wrote in message
news:9liemf\$s2r\$1 digitaldaemon.com...
I currently use many enumerated values in my code.  I find myself

setting
values for bit flags and other non-linear sets.  What do you think of

these
ideas? (Syntax is for illustration only.)

1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b

=
2,
c = 4, etc.

Since D supports bit arrays, bit flags may be more appropriate as a bit
array, with an ordinary enum indexing it.

2. Previous value plus n.  enum blah { a, b + 0xf, c, d, e + 0x3}; a =

0,
b
= 0xf, c = 0x10, d = 0x11, e = 0x14.

enum blah { a, b=a+0xf,c,d,e=d+3 }

3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0

so
you can find ranges without considering the names of the enumerations or
defining the ever-present MaxVal in your enumerations.

Done as blah.min and blah.max.

4. Continuation of enumerations.  class A{ enum mode {input, output}; };
Class B: public A{ enum(append) mode {io, null }; };.  Useful if you add
modes via inheritance (ie, io class -- which uses multiple inheritence,
btw).  Using this would allow you to add new modes without all the
dependencies on initial statement.
5. Access enumerations as arrays.  Using #4, mode[3] in the appended
enumeration yields the value for "io."  mode[3] in the un-appended

version
throws an exception.  You could remove values as well.
6. As text.  So, using #4 again, as_text(mode[0]) returns a char * to

the
string "input".

These are interesting ideas.
```
Dec 22 2001
"Pavel Minayev" <evilone omen.ru> writes:
```"Walter" <walter digitalmars.com> wrote in message
news:a02q8n\$hrt\$1 digitaldaemon.com...

Since D supports bit arrays, bit flags may be more appropriate as a bit
array, with an ordinary enum indexing it.

Still... compare the following snippets

enum { toread = 1, towrite = 2 }
void open(char[] filename, uint mode);

with:

void open(char[] filename, bit[2] mode);
open("blah.blah", [ toread: true, towrite: true ]);

I would personally prefer the first. On other hand, it would
be nice to have some special initializer for bit arrays - so
that we list the bits that should be turned on, and others
are set to zero, just like with bit flags.

5. Access enumerations as arrays.  Using #4, mode[3] in the appended
enumeration yields the value for "io."  mode[3] in the un-appended

version
throws an exception.  You could remove values as well.

Interesting.

6. As text.  So, using #4 again, as_text(mode[0]) returns a char * to

the
string "input".

Maybe as toString() method then? Could be of great use for I/O library,
to print enums as readable strings rather than numbers...
```
Dec 22 2001
"Walter" <walter digitalmars.com> writes:
```"Pavel Minayev" <evilone omen.ru> wrote in message
news:a02quf\$i71\$1 digitaldaemon.com...
"Walter" <walter digitalmars.com> wrote in message
news:a02q8n\$hrt\$1 digitaldaemon.com...

Since D supports bit arrays, bit flags may be more appropriate as a bit
array, with an ordinary enum indexing it.

Still... compare the following snippets

enum { toread = 1, towrite = 2 }
void open(char[] filename, uint mode);

with:

void open(char[] filename, bit[2] mode);
open("blah.blah", [ toread: true, towrite: true ]);

I would personally prefer the first.

You can still do the first in D.

On other hand, it would
be nice to have some special initializer for bit arrays - so
that we list the bits that should be turned on, and others
are set to zero, just like with bit flags.

```
Dec 22 2001
"Pavel Minayev" <evilone omen.ru> writes:
```"Walter" <walter digitalmars.com> wrote in message
news:a032at\$me1\$1 digitaldaemon.com...

You can still do the first in D.

I know because I use it that way =)

Nothing. But it'd be great if there were some
kind of syntactic sugar for that, maybe like
this?

```
Dec 23 2001
"Anthony Steele" <asteele nospam.iafrica.com> writes:
```"D Man" <clockwork austin.rr.com> wrote in message
news:9liemf\$s2r\$1 digitaldaemon.com...
I currently use many enumerated values in my code.  I find myself setting
values for bit flags and other non-linear sets.  What do you think of

these
ideas? (Syntax is for illustration only.)

1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b =

2,
c = 4, etc.

You are only doing this because you want to use a set, but don't know about
as you are used to coding in an inappropriately low-level syntax in C. Sure,
when you want to talk to the OS, you have to be reasonabley language-neutral
so bits are the thing to use, but maybe 90% of the flags might only be used

Delphi/Object pascal has many kimitations, but you can do this:

type
TOption = (caps, indent, bold, reverse);

type
TOptionSet = set of TOption;

procedure Demo;
var
myOptions1, myOptions2, myOptions3: TOptionSet;
begin
myOptions1 := [caps, indent];
myOptions2 := [bold, indent];
myOptions3 := myOptions1 + myOptions2; // union of 2 sets

if (indent in myOptions3) then // membership test
begin
...
end;

Sets are  implemented as bitmasks, but as a programmer you don't need to
worry about that, it just is good.
```
Sep 09 2001
"Anthony Steele" <asteele nospam.iafrica.com> writes:
```"D Man" <clockwork austin.rr.com> wrote in message
news:9liemf\$s2r\$1 digitaldaemon.com...
I currently use many enumerated values in my code.  I find myself setting
values for bit flags and other non-linear sets.  What do you think of

these
ideas? (Syntax is for illustration only.)

1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b =

2,
c = 4, etc.

You are only doing this because you want to use a set, but don't know about
as you are used to coding in an inappropriately low-level syntax in C. Sure,
when you want to talk to the OS, you have to be reasonabley language-neutral
so bits are the thing to use, but maybe 90% of the flags might only be used

Delphi/Object pascal has many kimitations, but you can do this:

type
TOption = (caps, indent, bold, reverse);

type
TOptionSet = set of TOption;

procedure Demo;
var
myOptions1, myOptions2, myOptions3: TOptionSet;
begin
myOptions1 := [caps, indent];
myOptions2 := [bold, indent];
myOptions3 := myOptions1 + myOptions2; // union of 2 sets

if (indent in myOptions3) then // membership test
begin
...
end;

Sets are  implemented as bitmasks, but as a programmer you don't need to
worry about that, it just is good.
```
Sep 09 2001