no_spam_anglewyrm@hotmail.com ("AngleWyrm") wrote (abridged):
> Creation of a new data type enum_t, which has this property: The only
> values in the enum_t set are mutually exclusive keywords.

So I wouldn't be able to use it in a case like:

    enum Colours { cyan=3, yellow, magenta, black };

because I wouldn't have control over the integer values? Then I also
wouldn't dare use it for cases which might evolve into that:

    enum Colours { red, green, blue, cyan, yellow, magenta, black };

if support for rgb could be dropped. It sounds to me as though you
are providing too small a subset of enum features to be useful.

I think there /are/ ways to make enum more useful, broadly by
identifying and distinguishing two kinds of enum: those used for
enumerations and those used for bitsets. And this distinction can
be expressed in code, probably by using inheritance or using
declarations.

-- Dave Harris, Nottingham, UK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20040222014235.780A@brangdon.m...
> no_spam_anglewyrm@hotmail.com ("AngleWyrm") wrote (abridged):
> > Creation of a new data type enum_t, which has this property: The only
> > values in the enum_t set are mutually exclusive keywords.
>
> So I wouldn't be able to use it in a case like:
>     enum Colours { cyan=3, yellow, magenta, black };
> because I wouldn't have control over the integer values?

The limiting factors expressed in the statement "The only values in the
enum_t set are mutually exclusive keywords" are (1) that they be mutually
exclusive (no duplicates), and (2) that they be the entire domain (no other
values are valid).

Thus, with the enum_t, the proposed expression is valid:
enum_t Colours { cyan=3, yellow, magenta, black };
and evaluates to the set of values { 3, 4, 5, 6 }.

As for limiting programmer's abilities to think about and solve problems,
the enum_t actually enhances a programmer's abilities, by making some types
of problems easier to think about and solve, and this, IMO, is what a good
language is all about.

PROPOSED ENUM_T CODE:

// First example of casting from float to enum_t
enum_t Grades { GREAT = 4, GOOD = 3, OK= 2, WEAK=1, LOSER=0 };
float studentGrade = CalculateGPA( student ); // gather data on student

switch( (Grades)studentGrade ) { // cast float to enum_t
    case GREAT:
    case GOOD:
        cout << "you deserve a treat" << endl;
        break;
    case OK:
    case WEAK:
        cout << "hit the books" << endl;
        break;
    case LOSER:
        cout << "would you like fries with that?" << endl;
   default:
        cout << "internal error" << endl;
}

// second example of casting: int to enum_t
enum_t categories {
    COMMON  = RAND_MAX * 2/3,
    UNCOMMON  = RAND_MAX * 4/5,
    RARE = RAND_MAX * 19/20,
    VERY_RARE = RAND_MAX
}
categories etFreqency;
etFrequency = (categories) rand(); // cast int to enum_t
if( etFrequency == VERY_RARE ){
    // special event
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20040222014235.780A@brangdon.m...
> no_spam_anglewyrm@hotmail.com ("AngleWyrm") wrote (abridged):
> > Creation of a new data type enum_t, which has this property: The only
> > values in the enum_t set are mutually exclusive keywords.
>
> So I wouldn't be able to use it in a case like:
>     enum Colours { cyan=3, yellow, magenta, black };
> because I wouldn't have control over the integer values?

The limiting factors expressed in the statement "The only values in the
enum_t set are mutually exclusive keywords" are (1) that they be mutually
exclusive (no duplicates), and (2) that they be the entire domain (no other
values are valid).

Thus, with the enum_t, the proposed expression is valid:
enum_t Colours { cyan=3, yellow, magenta, black };
and evaluates to the set of values { 3, 4, 5, 6 }.

As for limiting programmer's abilities to think about and solve problems,
the enum_t actually enhances a programmer's abilities, by making some types
of problems easier to think about and solve, and this, IMO, is what a good
language is all about.

PROPOSED ENUM_T CODE:

// First example of casting from float to enum_t
enum_t Grades { GREAT = 4, GOOD = 3, OK= 2, WEAK=1, LOSER=0 };
float studentGrade = CalculateGPA( student ); // gather data on student

switch( (Grades)studentGrade ) { // cast float to enum_t
    case GREAT:
    case GOOD:
        cout << "you deserve a treat" << endl;
        break;
    case OK:
    case WEAK:
        cout << "hit the books" << endl;
        break;
    case LOSER:
        cout << "would you like fries with that?" << endl;
   default:
        cout << "internal error" << endl;
}

// second example of casting: int to enum_t
enum_t categories {
    COMMON  = RAND_MAX * 2/3,
    UNCOMMON  = RAND_MAX * 4/5,
    RARE = RAND_MAX * 19/20,
    VERY_RARE = RAND_MAX
}
categories etFreqency;
etFrequency = (categories) rand(); // cast int to enum_t
if( etFrequency == VERY_RARE ){
    // special event
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

First, let me recognize the hard work, and historical necessity of the way
things are. Secondly, recognize also, the value of the standards committee,
and their ongoing efforts to improve the language. And let me add that C++
is also my most used language, thus my favorite.

This is a look into the definition of the enumeration data type, with an
expose on some types of problems that can come up, and a possible
recommendation for a new type, enum_t.


PURPOSE AND REASON

As I understand it, the enum keyword supports two ideoms, one is a set of
discreet named constants, and the other is bit manipulations within a range.
It is my belief that because this datatype is pulling double-duty, it must
of necessity perform at less than optimal in at least one of these fields of
endeavor. (Illustrations below). Furthermore, because it has done so for
years, depreciation of one or the other of those duties seems unreasonable
at this time, for it would break the installed code base currently in use.

First Illustration: In situations where enums are used for a switch/case
evaluation, it was recommended by Bjarne Stroustrup[1] that "A compiler can
issue a warning because only two out of three keyword values are handled".
This does not seem to be the case:

enum keyword { ASM, AUTO, BREAK };
void f( keyword key){
    switch(key){
        case ASM:
            // do something
            break;
        case BREAK:
            // do something
            break;
    }
}

Second Illustration: Enumerations are not guaranteed to be unique valued,
and this can cause problems both in the switch/case scenario and in if/then
tests.

enum manyKeys { ASM = 0xfa46, /* many entries here */, JMP = 0xfa46 };

The compiler will register the enumeration as acceptible, but will stop at
the switch/case, unable to resolve a duplicate case value. A more accurate
declaration of the problem at hand is the non-unique enumeration.

Third Illustration: If the above enumeration is instead used in if/then
clauses, logical bugs can appear:

manyKeys eVariable = ASM, eSecondVariable = JMP;
if ( eVariable == JMP ){
    cout << "faulty code" << endl; // fails to differentiate between ASM &
JMP
}
if( eVariable == eSecondVariable ){
    cout << "erroneous conclusion" << endl;
}

Fourth Illustration: Iteration and Looping must be programmatically added by
use of other means, which often involves an array, requiring compile-time
knowledge of the number of keywords in the enumeration. Determining the
number of keywords in an enumeration is commonly done by assigning an
additional keyword to the enum:

enum colorSet { RED, WHITE, BLUE, MAXCOLORS };

This undermines the usefulness of assigning values to the enumeration, and
to my mind it overloads the colorSet enumeration with the double duty of
maintaining information that is outside it's specific task.


RECOMMENDATION

Creation of a new data type enum_t, which has this property: The only values
in the enum_t set are mutually exclusive keywords.

It can then be thought of as subdividing/categorizing a domain or problem
space. This is an excellent property, and can be extended quite usefully
with type casting: Consider the conversion of a float to an int: The value
of one is mapped to a new domain. Now consider mapping any integer into a
programmer-specified number of options, with each one given a specific
value. It would make thinking about and implementing that type of problem
more accessible.

Furthermore, if the enum_t datatype is mutually exclusive and limited to the
set, then it is both sortable and iteratable.


Thank you for taking the time to consider this proposal, and please
contribute any ideas.

---
[1] "The C++ Programming Language", Bjarne Stroustrup, copywright 1997,
section 4.8 pp77

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]