www.digitalmars.com         C & C++   DMDScript  

D - super duper enumerations

reply "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
next sibling parent "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 =

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
prev sibling next sibling parent reply 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
next sibling parent reply "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


 throws an exception.  You could remove values as well.

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

 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 class reader output: Available modes: exists read class writer output: Available modes: exists write class read_write output: Available modes: exists read write
Aug 17 2001
next sibling parent "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
prev sibling next sibling parent 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
prev sibling parent reply "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


 throws an exception.  You could remove values as well.

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

 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
parent reply 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
parent "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

 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
prev sibling parent "Anthony Steele" <asteele nospam.iafrica.com> writes:
 3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0


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

YES!

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
prev sibling next sibling parent reply "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

 ideas? (Syntax is for illustration only.)

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

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

 = 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
next sibling parent 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 };
enum filemode(bitmask) { Read, Write, Truncate };

state = Init;
filemode = Read | Write;
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
prev sibling parent reply "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


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

 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 =


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


Already supported as: enum blah { a, b=a+0xf,c,d,e=d+3 }
 3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0


 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


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


 string "input".


These are interesting ideas.
Dec 22 2001
parent reply "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); open("blah.blah", toread | towrite); with: enum { toread, towrite } 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


 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


 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
parent reply "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); open("blah.blah", toread | towrite); with: enum { toread, towrite } 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.

What's wrong with [toread:true, towrite:true]?
Dec 22 2001
parent "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 =)
 What's wrong with [toread:true, towrite:true]?

Nothing. But it'd be great if there were some kind of syntactic sugar for that, maybe like this? [[toread, towrite]]
Dec 23 2001
prev sibling next sibling parent "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

 ideas? (Syntax is for illustration only.)

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

 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 inside your program. 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
prev sibling parent "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

 ideas? (Syntax is for illustration only.)

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

 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 inside your program. 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