www.digitalmars.com         C & C++   DMDScript  

D - Arrays that parallel an enum

reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
Walter,

I read on DigitalMars' website, under the "Arrays that parallel an enum"
paragraph in the "Converting C to D" section (
http://www.digitalmars.com/d/ctod.html#arrayenum ) that Walter defines the D
way of declaring such an array "not perfect, but better" with respect to the
C (no-) way. Maybe suggestions on this have already been given, but how
about something like:

enum COLORS { red, blue, green }
char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];

In other words, take an enum type name as synonim for its range wherever a
range is expected or allowed, then (here pardon my ignorance about compiler
theory) make the enum a default namespace with regard to the array index.
I know it looks a lot like Delphi... as a matter of fact, a *lot* of D
already does. Just add bitfields, subrange types and Pascal-like sets to D,
and it's the language of my wildest dreams (er, my wildest *programming*
dreams ;-) ), that is, more concise than C/C++, as formal as Delphi (I
intentionally don't mention "plain" Pascal which is even too formal for
real-world use) and even more fun than Basic to use.

Anyway, regardless of your decisions about subranges and sets, D really
ROCKS! (In case you're wondering, yes, I'm one of those who set maximum
warning level, warnings as errors, etc. etc.)

Bye & Thanks
Ric
Jul 30 2003
parent reply "Walter" <walter digitalmars.com> writes:
That is a good idea. -Walter

"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bg8p6j$1idv$1 digitaldaemon.com...

 Walter,

 I read on DigitalMars' website, under the "Arrays that parallel an enum"
 paragraph in the "Converting C to D" section (
 http://www.digitalmars.com/d/ctod.html#arrayenum ) that Walter defines the


D

 way of declaring such an array "not perfect, but better" with respect to


the

 C (no-) way. Maybe suggestions on this have already been given, but how
 about something like:

 enum COLORS { red, blue, green }
 char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];

 In other words, take an enum type name as synonim for its range wherever a
 range is expected or allowed, then (here pardon my ignorance about


compiler

 theory) make the enum a default namespace with regard to the array index.
 I know it looks a lot like Delphi... as a matter of fact, a *lot* of D
 already does. Just add bitfields, subrange types and Pascal-like sets to


D,

 and it's the language of my wildest dreams (er, my wildest *programming*
 dreams ;-) ), that is, more concise than C/C++, as formal as Delphi (I
 intentionally don't mention "plain" Pascal which is even too formal for
 real-world use) and even more fun than Basic to use.

 Anyway, regardless of your decisions about subranges and sets, D really
 ROCKS! (In case you're wondering, yes, I'm one of those who set maximum
 warning level, warnings as errors, etc. etc.)

 Bye & Thanks
 Ric
Aug 10 2003
next sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
There is an easier way, in my opinion than enums: the set. A 'set' could be
a foundamental element of the language. A set could contain anything, not
only integers. Of course, integers would be automatically enumerated. Its
syntax could be:

<type> set <name> = { <comma separated list of values> }

For example:

//color enum
int set COLORS = {
    RED,
    GREEN,
    BLUE
}

//days
string set DAYS = {
    SUNDAY = "Sunday",
    MONDAY = "Monday",
    TUESDAY = "Tuesday"
}

//bitfield set
bit[2] set STATE = {
    STATE_GREEN,
    STATE_RED,
    STATE_YELLOW,
    STATE_CYAN
}

A set could have many static properties useful in run-time:

FIRST = first value
LAST = last value
operator [int] = access value by index
operator [string] = access value by name
COUNT = number of values
NAME[int]  = access each set member's name as a string

It would certainly be better than simple enums; more readable, strongly
typed; it would be of user-defined size (so structs that map to binary
formats would be easier to code); the run-time type static information would
be useful to gui IDEs...there are many advantages to it.

"Walter" <walter digitalmars.com> wrote in message
news:bh67dt$25nl$1 digitaldaemon.com...

 That is a good idea. -Walter

 "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
 news:bg8p6j$1idv$1 digitaldaemon.com...

 Walter,

 I read on DigitalMars' website, under the "Arrays that parallel an enum"
 paragraph in the "Converting C to D" section (
 http://www.digitalmars.com/d/ctod.html#arrayenum ) that Walter defines




the

 D

 way of declaring such an array "not perfect, but better" with respect to


 the

 C (no-) way. Maybe suggestions on this have already been given, but how
 about something like:

 enum COLORS { red, blue, green }
 char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];

 In other words, take an enum type name as synonim for its range wherever




a

 range is expected or allowed, then (here pardon my ignorance about


 compiler

 theory) make the enum a default namespace with regard to the array




index.

 I know it looks a lot like Delphi... as a matter of fact, a *lot* of D
 already does. Just add bitfields, subrange types and Pascal-like sets to


 D,

 and it's the language of my wildest dreams (er, my wildest *programming*
 dreams ;-) ), that is, more concise than C/C++, as formal as Delphi (I
 intentionally don't mention "plain" Pascal which is even too formal for
 real-world use) and even more fun than Basic to use.

 Anyway, regardless of your decisions about subranges and sets, D really
 ROCKS! (In case you're wondering, yes, I'm one of those who set maximum
 warning level, warnings as errors, etc. etc.)

 Bye & Thanks
 Ric
Aug 11 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
I'd rather have set apply to any type, but not define the possible values at
the set declaration.

Like so:

set(int) intset = { 0, 5, 7 }; // make a set that can hold any int, but for
now holds only 0, 5, and 7

enum days { SUNDAY = "Sunday", MONDAY = "Monday", TUESDAY = "Tuesday" }
set(days) daysset = { MONDAY };

range(int, 0, 7) threebitrange;
set(threebitrange) threebitset;
threebitset.insert(2);
threebitset.insert(5);
threebitset.erase(2);
// now holds just 5

There are various ways sets can be implemented, depending on whether the
number of possible values is large or small.  It can be anything from a
simple array to a red/black tree, or any number of other implementations.
It should be up to the compiler and transparent to the user.

Yes you 'could' probably do this in a user-defined library, but you wouldn't
get any syntax sugar from the language to make it easier to use, that way.

Sean

"Achilleas Margaritis" <axilmar in.gr> wrote in message
news:bh8473$11cp$1 digitaldaemon.com...

 There is an easier way, in my opinion than enums: the set. A 'set' could


be

 a foundamental element of the language. A set could contain anything, not
 only integers. Of course, integers would be automatically enumerated. Its
 syntax could be:

 <type> set <name> = { <comma separated list of values> }

 For example:

 //color enum
 int set COLORS = {
     RED,
     GREEN,
     BLUE
 }

 //days
 string set DAYS = {
     SUNDAY = "Sunday",
     MONDAY = "Monday",
     TUESDAY = "Tuesday"
 }

 //bitfield set
 bit[2] set STATE = {
     STATE_GREEN,
     STATE_RED,
     STATE_YELLOW,
     STATE_CYAN
 }

 A set could have many static properties useful in run-time:

 FIRST = first value
 LAST = last value
 operator [int] = access value by index
 operator [string] = access value by name
 COUNT = number of values
 NAME[int]  = access each set member's name as a string

 It would certainly be better than simple enums; more readable, strongly
 typed; it would be of user-defined size (so structs that map to binary
 formats would be easier to code); the run-time type static information


would

 be useful to gui IDEs...there are many advantages to it.

 "Walter" <walter digitalmars.com> wrote in message
 news:bh67dt$25nl$1 digitaldaemon.com...

 That is a good idea. -Walter

 "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
 news:bg8p6j$1idv$1 digitaldaemon.com...

 Walter,

 I read on DigitalMars' website, under the "Arrays that parallel an






enum"

 paragraph in the "Converting C to D" section (
 http://www.digitalmars.com/d/ctod.html#arrayenum ) that Walter defines




 the

 D

 way of declaring such an array "not perfect, but better" with respect






to

 the

 C (no-) way. Maybe suggestions on this have already been given, but






how

 about something like:

 enum COLORS { red, blue, green }
 char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];

 In other words, take an enum type name as synonim for its range






wherever

 a

 range is expected or allowed, then (here pardon my ignorance about


 compiler

 theory) make the enum a default namespace with regard to the array




 index.

 I know it looks a lot like Delphi... as a matter of fact, a *lot* of D
 already does. Just add bitfields, subrange types and Pascal-like sets






to

 D,

 and it's the language of my wildest dreams (er, my wildest






*programming*

 dreams ;-) ), that is, more concise than C/C++, as formal as Delphi (I
 intentionally don't mention "plain" Pascal which is even too formal






for

 real-world use) and even more fun than Basic to use.

 Anyway, regardless of your decisions about subranges and sets, D






really

 ROCKS! (In case you're wondering, yes, I'm one of those who set






maximum

 warning level, warnings as errors, etc. etc.)

 Bye & Thanks
 Ric
Aug 11 2003
prev sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Achilleas Margaritis" <axilmar in.gr> ha scritto nel messaggio
news:bh8473$11cp$1 digitaldaemon.com...


 There is an easier way, in my opinion than enums: the set. A 'set' could


be

 a foundamental element of the language. A set could contain anything, not
 only integers. Of course, integers would be automatically enumerated. Its
 syntax could be:

 <type> set <name> = { <comma separated list of values> }
 [...]
 It would certainly be better than simple enums; more readable, strongly
 typed; it would be of user-defined size (so structs that map to binary
 formats would be easier to code); the run-time type static information


would

 be useful to gui IDEs...there are many advantages to it.


I personally find this to be a great idea but, as far as I understand, set
is not the appropriate name for it, maybe due to my Pascal / Delphi
background...
What you described is very nice, but looks in the middle between
enumerations and associative arrays, plus some cool features of its own.
I'd prefer a different keyword to be used for it it if ever gets
implemented, leaving out "set" in the hope that one day D has Pascal-like
sets, which I really miss when I use C / C++.

Ric
Aug 25 2003
prev sibling parent reply Simon J Mackenzie <project.d smackoz.fastmail.fm> writes:
Another good/not so good thought, if enumerated types could support 
negative values with Riccardo's proposed format then any system error 
numbers could be directly mapped to error message strings making the 
support of system error messages in D very straight forward.

eg.

enum NETDB_ERROR_MSG : int
{
    NETDB_INTERNAL  = -1,
    NETDB_SUCCESS   =  0,
    HOST_NOT_FOUND  =  1,
    TRY_AGAIN       =  2,
    NO_RECOVERY     =  3,
}

char[NETDB_ERROR_MSG][] NETDB_ERROR =
[
    NETDB_INTERNAL: "NETDB_INTERNAL, See errno.",
    NETDB_SUCCESS: "NETDB_SUCCESS, No problem.",
    HOST_NOT_FOUND : "HOST_NOT_FOUND, Authoritative Answer Host ...",
    TRY_AGAIN : "TRY_AGAIN, Non-Authoritative Host not found or ...",
    NO_RECOVERY : "NO_RECOVERY, Non recoverable errors, FORMERR,..."
];

Final result: With this code no switch/if statements needed for any 
error generated from the system call!

HostSystemCall();
printf("Some error message header, %.*s", NETDB_ERROR[getHostErrno()]);



Any thoughts

Simon

Walter wrote:

 That is a good idea. -Walter



enum COLORS { red, blue, green }
char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];
Aug 20 2003
parent "Charles Sanders" <sanders-consulting comcast.net> writes:
 char[NETDB_ERROR_MSG][] NETDB_ERROR =
 [
     NETDB_INTERNAL: "NETDB_INTERNAL, See errno.",
     NETDB_SUCCESS: "NETDB_SUCCESS, No problem.",
     HOST_NOT_FOUND : "HOST_NOT_FOUND, Authoritative Answer Host ...",
     TRY_AGAIN : "TRY_AGAIN, Non-Authoritative Host not found or ...",
     NO_RECOVERY : "NO_RECOVERY, Non recoverable errors, FORMERR,..."
 ];



Is this syntax (initalizing associatvie arrays ) in the new compiler ?

Charles


"Simon J Mackenzie" <project.d smackoz.fastmail.fm> wrote in message
news:bhvlaq$1ri7$1 digitaldaemon.com...

 Another good/not so good thought, if enumerated types could support
 negative values with Riccardo's proposed format then any system error
 numbers could be directly mapped to error message strings making the
 support of system error messages in D very straight forward.

 eg.

 enum NETDB_ERROR_MSG : int
 {
     NETDB_INTERNAL  = -1,
     NETDB_SUCCESS   =  0,
     HOST_NOT_FOUND  =  1,
     TRY_AGAIN       =  2,
     NO_RECOVERY     =  3,
 }

 char[NETDB_ERROR_MSG][] NETDB_ERROR =
 [
     NETDB_INTERNAL: "NETDB_INTERNAL, See errno.",
     NETDB_SUCCESS: "NETDB_SUCCESS, No problem.",
     HOST_NOT_FOUND : "HOST_NOT_FOUND, Authoritative Answer Host ...",
     TRY_AGAIN : "TRY_AGAIN, Non-Authoritative Host not found or ...",
     NO_RECOVERY : "NO_RECOVERY, Non recoverable errors, FORMERR,..."
 ];

 Final result: With this code no switch/if statements needed for any
 error generated from the system call!

 HostSystemCall();
 printf("Some error message header, %.*s", NETDB_ERROR[getHostErrno()]);



 Any thoughts

 Simon

 Walter wrote:

 That is a good idea. -Walter



enum COLORS { red, blue, green }
char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];
Aug 20 2003