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.

enumeration yields the value for "io."  mode[3] in the un-appended version
throws an exception.  You could remove values as well.

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 =


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.

enumeration yields the value for "io."  mode[3] in the un-appended version
throws an exception.  You could remove values as well.

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.



 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.




 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();



 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

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();
 


 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
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


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


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.

 enumeration yields the value for "io."  mode[3] in the un-appended version
 throws an exception.  You could remove values as well.

 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




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.




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




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.

 enumeration yields the value for "io."  mode[3] in the un-appended




version

 throws an exception.  You could remove values as well.





the

 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.



 enumeration yields the value for "io."  mode[3] in the un-appended




 version

 throws an exception.  You could remove values as well.






Interesting.







 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
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


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
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


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
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