David R Tribble writes:
>> At the risk of having large objects thrown in my direction, how about:
>>
>>     enum<long> E { A, B };
>>
>> On second thought, maybe not.  While the syntax fits in fairly well with
>> existing C++ syntax, it adds those infernal '<>' brackets to C, which many
>> might consider a Bad Thing.

llewelly wrote:
> [...]
> Even though I prefer <> visually, I wish C++ had used {}, [], or () ;
>     using <> for templates is one more thing that makes C++ difficult
>     to parse, and the result is that good tools for C++ are harder to
>     write and less common. I don't know if it would have been
>     worthwile to extend the character set, but I think that would
>     have been a hard sell.

There are all sorts of combinations of possible bracket tokens, e.g.:

    [x]       [[x]]
    <x>       <<x>>      <=x=>
    {x}       {{x}}
    (x)       (|x|)      |x|       <|x|>    <~x~>
    /x/       ^x^        =x=       ~x~

    enum Shade^long { ... };
    enum Shade[long] { ... };
    enum Shade[[long]] { ... };
    etc.


But if we're limiting the discussion to the possible syntax for type-embued
enums, then
    enum Shade: long { ... };
would get my vote, if for no other reasons than it's the simplest and adds
the least amount of clutter.  It also resembles class inheritance, which
makes a certain amount of sense.


>     I prefer 'and' to '&&', so my sense of aesthetics might be
>     considered questionable. :-)

As of about two years ago, I started using 'not', 'and', and 'or' instead of
their equivalent punctuation in all of my C and C++ code.  But there are still
a few C++ compilers that don't get these right.

-drt

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

Francis Glassborow wrote:
>> So perhaps wchar_t will get re-instated. However note that that might be
>> a problem for C because it isn't a fundamental type in C.

Obviously, C would only allow C types, and C++ would only allow C++ types.
But either should allow typedef names as well as fundamental integer types,
too.

    enum SpecialChars: wchar_t    // typedef in C, basic type in C++
    {
        UNIC_NUL =    0x0000,
        UNIC_BOC =    0xFEFF,
        UNIC_BOC_R =  0xFFFE,
        UNIC_NAC =    0xFFFF,
        ...
    };


Wojtek Lerch wrote:
> C doesn't even define the term "fundamental type", does it...  Are you
> saying that in C, it could be a problem to make this mechanism work with
> extended integer types?  Or maybe with typedefs in general?  Wouldn't it
> be useful if it worked with things like size_t or uint16_t?

And don't forget 'bool' (and '_Bool').

    enum SwitchType: bool { ON, OFF };

-drt

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

Walter, of D fame, wrote:
> For some prior art examples, D's enums already implement this (though not
> exactly the same syntax, and D enums still allow implicit promotion to
> integral type). For example:
>
> enum { A, B }    // A=0 and B=1, are int's, in the current scope
> enum E {A,B}    // A and B are in E's scope, i.e. E.A and E.B.
> enum : long { A,B }    // A=0 and B=1, and are long's
> enum F : long {A,B}    // F.A =0 and F.B=1 and are long's
>
> D enums: www.digitalmars.com/d/enum.html

At the risk of having large objects thrown in my direction, how about:

    enum<long> E { A, B };

On second thought, maybe not.  While the syntax fits in fairly well with
existing C++ syntax, it adds those infernal '<>' brackets to C, which many
might consider a Bad Thing.  I know that one thing I really hate about C++
is that the use of even the simplest template syntax quickly makes code
highly cluttered and unreadable.  I don't think I could stand being blamed
for corrupting C in the same way.


[BTW, one nice addition to C99 was allowing a trailing ',' on the last
enum constant within an enum declaration, a la array initializers.  Bravo.
Hopefully C++0X will adopt this.]

-drt

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

david@tribble.com (David R Tribble) writes:
[...]
> And don't forget 'bool' (and '_Bool').
>
>     enum SwitchType: bool { ON, OFF };
>
> -drt

Please tell me you meant

    enum SwitchType: bool { OFF, ON };

Either is legal, of course, but the former is likely to cause confusion.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

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

"David R Tribble" <david@tribble.com> wrote in message
news:f4002eab.0405030824.32423405@posting.google.com...
> At the risk of having large objects thrown in my direction, how about:
>
>     enum<long> E { A, B };
>
> On second thought, maybe not.  While the syntax fits in fairly well with
> existing C++ syntax, it adds those infernal '<>' brackets to C, which many
> might consider a Bad Thing.  I know that one thing I really hate about C++
> is that the use of even the simplest template syntax quickly makes code
> highly cluttered and unreadable.  I don't think I could stand being blamed
> for corrupting C in the same way.

I never liked the <> for template parameters. My brain just refuses to
recognize them as being other than expression operators. (It causes grief in
the C++ lexer & parser, too.) The D solution to this is, instead of
identifier<arg>, it has identifier!(arg):

template Foo(T) { ... }

Foo!(int)            // instantiate Foo with 'int'

It looks a bit odd at first, but one rapidly becomes accustomed to it. It
fits in cleanly with parsing, too, as ! is never used as a binary operator.
No tortuous grammar or special semantic rules are needed.
www.digitalmars.com/d/template.html

> [BTW, one nice addition to C99 was allowing a trailing ',' on the last
> enum constant within an enum declaration, a la array initializers.  Bravo.
> Hopefully C++0X will adopt this.]

D adopts it too. It's an obviously good idea.

-Walter
www.digitalmars.com free C/C++/D compilers

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

david@tribble.com (David R Tribble) writes:

> Walter, of D fame, wrote:
>> For some prior art examples, D's enums already implement this (though not
>> exactly the same syntax, and D enums still allow implicit promotion to
>> integral type). For example:
>>
>> enum { A, B }    // A=0 and B=1, are int's, in the current scope
>> enum E {A,B}    // A and B are in E's scope, i.e. E.A and E.B.
>> enum : long { A,B }    // A=0 and B=1, and are long's
>> enum F : long {A,B}    // F.A =0 and F.B=1 and are long's
>>
>> D enums: www.digitalmars.com/d/enum.html
>
> At the risk of having large objects thrown in my direction, how about:
>
>     enum<long> E { A, B };
>
> On second thought, maybe not.  While the syntax fits in fairly well with
> existing C++ syntax, it adds those infernal '<>' brackets to C, which many
> might consider a Bad Thing.
[snip]

The real problem is that the C basic character set does not contain
    angle brackets which are distinct from comparison operators. If
    you look at almost any mathematical text using angle brackets,
    you'll see they are visually distinct from less-than and
    greater-than.

The C basic character set can't express angle brackets. (ab)using
    less-than and greater-than for this purpose is a kludge. It
    causes problems with parsing C++, and also with defining C++;
    there have been a few Core issues opened about when '<' is less
    then, and when it is the start of template arguments.

Even though I prefer <> visually, I wish C++ had used {}, [], or () ;
    using <> for templates is one more thing that makes C++ difficult
    to parse, and the result is that good tools for C++ are harder to
    write and less common. I don't know if it would have been
    worthwile to extend the character set, but I think that would
    have been a hard sell.

I don't think C should consider using less-than and greater-than as
    angle-brackets for any feature. (Other C++ compatible
    templates, which seems an unlikely addition to C .)

> I know that one thing I really hate about C++
> is that the use of even the simplest template syntax quickly makes code
> highly cluttered and unreadable.

I don't have this problem. I find angle brackets readable and
    aestheticlly appealing in all but a few pathological cases. (Of
    course, I prefer 'and' to '&&', so my sense of aesthetics might be
    considered questionable. :-) My problem is that C++ doesn't
    have angle brackets; it only has something which looks like them.


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

llewelly wrote:
> The real problem is that the C basic character set does not contain
>     angle brackets which are distinct from comparison operators. If
>     you look at almost any mathematical text using angle brackets,
>     you'll see they are visually distinct from less-than and
>     greater-than.

They wouldn't be in this instance.  C already uses <...>
as brackets in #include directives.

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

DAGwyn@null.net ("Douglas A. Gwyn") writes:

> llewelly wrote:
>> The real problem is that the C basic character set does not contain
>>     angle brackets which are distinct from comparison operators. If
>>     you look at almost any mathematical text using angle brackets,
>>     you'll see they are visually distinct from less-than and
>>     greater-than.
>
> They wouldn't be in this instance.  C already uses <...>
> as brackets in #include directives.

But those only affect the preprocessor, and are always preceded by
    #include. That's a vastly simpler use than <> for C++ template
    arguments. The problems I talked about don't arise in that case.

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

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:mNOG98AYlLjAFw20@robinton.demon.co.uk...
> In message <uobo80h2jappn129d4uk2u3duilp56jief@4ax.com>, Jack Klein
> <jackklein@spamcop.net> writes
> >I have long felt that the implementation of enumerations in both C and
> >C++, while different from each other, could be improved in a simple
> >way to provide greater utility.  I have used C-style casts, headers,
> >and pointers, rather than references, in the proposal since they are
> >common to both languages, not to slight the C++ features.
>
> Read the following and then track what happens to it. The Evolution work
> group encouraged the authors to develop much of it further though they
> were not keen on all of it.
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf

For some prior art examples, D's enums already implement this (though not
exactly the same syntax, and D enums still allow implicit promotion to
integral type). For example:

enum { A, B }    // A=0 and B=1, are int's, in the current scope
enum E {A,B}    // A and B are in E's scope, i.e. E.A and E.B.
enum : long { A,B }    // A=0 and B=1, and are long's
enum F : long {A,B}    // F.A =0 and F.B=1 and are long's

D enums: www.digitalmars.com/d/enum.html

-Walter
www.digitalmars.com free C/C++/D compilers

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

Francis Glassborow wrote:
> So perhaps wchar_t will get re-instated. However note that that might be
> a problem for C because it isn't a fundamental type in C.

C doesn't even define the term "fundamental type", does it...  Are you
saying that in C, it could be a problem to make this mechanism work with
extended integer types?  Or maybe with typedefs in general?  Wouldn't it
be useful if it worked with things like size_t or uint16_t?

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

On 2004-04-27 18:20, Francis Glassborow wrote:
> In message <73lq805gq6nm6pqujatc0aulgvvgcn6umq@4ax.com>, Brian Inglis
><Brian.Inglis@SystematicSw.Invalid> writes
:
> In fact WG21 is not looking at enum class as any kind of class,
> it is merely reusing a keyword as a descriminator from classic enum.
> If C wished to provide a similar facility I think it could do so
> with the same syntax and semantics.

In which case it would be better to not use a C++-only keyword
(e.g. 'typedef' instead of 'class'), unless someone manages to
convince WG14 that contextual keywords are an acceptable idea.

-- Niklas Matthies

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

I have long felt that the implementation of enumerations in both C and
C++, while different from each other, could be improved in a simple
way to provide greater utility.  I have used C-style casts, headers,
and pointers, rather than references, in the proposal since they are
common to both languages, not to slight the C++ features.

Proposal: typed enumerations.

An enumeration definition will be allowed to include the name of any
arithmetic type, example:

  enum unsigned int ui { BIT_0 = 1, BIT_1 = 2 };
  enum long double ld { PI = 3.14159 };

Such typed enumeration definitions could be named or nameless.

Such typed enumerations would have two features that current
enumerations would not have:

1. Objects of such enumerations would specifically be of the defined
type, example:

  ui my_ui; /* C++ only */
  enum ui my_ui; /* C or C++ */

The object my_ui would be an unsigned int, as opposed the current
enumerations where the implementation is free to select any integer
type that can hold the values 1 and 2.

2. Enumeration constants of such typed enumerations would have the
type of the enumeration, example:

  int x = BIT_0;  /* BIT_0 is equivalent to "1U", not to "(int)1" */

  float f;
  /* code which assigns some value to f */
  if (f < PI)  /* PI is equivalent to "3.14159L" or "(long
double)3.14159" */

Usefulness:

1. Interface (both languages).  Often system calls, third party
libraries, and various other APIs are implemented with the caller
passing a pointer (or perhaps a reference in C++) to one or more
objects to be assigned.

Consider a made-up example for a database query function (assume
appropriate definitions for types):

api_header.h:
----------
#define RECORD_FOUND            0
#define RECORD_NOT_FOUND        1
#define RECORD_BAD_QUERY        2
#define RECORD_NO_DATABASE_OPEN 3

/* returns a pointer to the record if the query succeeds */
/* or NULL if the query fails                            */
record *query_database(const char *the_query, int *res);
----------

In order to use this function one does something like this:

void some_func(args)
{
  record *my_data;
  int my_result;

  my_data = query_database("some string", &my_result);
  if (!my_data)
  {
    /* examine result code for reason for failure */
    switch (my_result)
    {
      /* ... */
    }
  }
}

While this is legal in both languages, we are stuck with the use of
macros.  It would be beneficial to be able to do this:

api_header.h:
----------
typedef enum {
  RECORD_FOUND,
  RECORD_NOT_FOUND,
  RECORD_BAD_QUERY,
  RECORD_NO_DATABASE_OPEN
 } query_result;

/* returns a pointer to the record if the query succeeds */
/* or NULL if the query fails                            */
record *query_database(const char *the_query, query_result *res);
----------

void some_func(args)
{
  record *my_data;
  query_result result;

  my_data = query_database("some string", &result);
  if (!my_data)
  {
    /* examine result code for reason for failure */
    switch (result)
    {
      /* ... */
    }
  }
}

The problem with the second usage is that the library and the compiler
may choose different underlying types for the query_result
enumeration, especially if one is supplied as a pre-build library from
a separate vendor.  The library code might use ints for all
enumeration types, the application might used one of the character
types because the values, 0 through 3, will fit in a character type.

2. Definition of constants (primarily in C):

C++ has largely eliminated the need for using macros to define
constants of arithmetic type by its specification of const qualified
built-in objects defined at file/namespace scope to have internal
linkage by default, and establishing the expectation that compilers
will not actually create such objects if their address is not taken.

The same could be done by C compilers if the file scope object is
defined with the static keyword, but in general they do not.  Even
implementations that come with both C and C++ compilers.

Given the silly example:

#include <stdio.h>

static const int x = 3;

int main(int argc, char **argv)
{
  if (argc == x)
  {
    puts("3 arguments");
  }
  else
  {
    puts("not e arguments");
  }
  return 0;
}

C++ compilers will not instantiate x, even without "static", whereas
many (most?) C compilers will.

So this proposal will allow:

  enum long double { PI=3.14159, E=2.71828 };

..to be functionally equivalent to:

  const long double PI=3.14159;
  const long double E=2.71828;

..in C++ and to:

  #define PI 3.14159L
  #define E  2.71828L

..in both languages.

Impact:

I have never implemented a parser for a C or C++ compiler, but
hopefully it would be possible to add this, or something similar,
without major effort and it should not break any existing code.

Conclusion:

I think the benefit to more readable code and better interface
definitions in both languages would outweigh the relatively minor (I
hope) effort of adding the language change.

I am interested in all feedback, especially from any compiler
implementers about my assessment of the magnitude of the change.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

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

In message <uobo80h2jappn129d4uk2u3duilp56jief@4ax.com>, Jack Klein
<jackklein@spamcop.net> writes
>I have long felt that the implementation of enumerations in both C and
>C++, while different from each other, could be improved in a simple
>way to provide greater utility.  I have used C-style casts, headers,
>and pointers, rather than references, in the proposal since they are
>common to both languages, not to slight the C++ features.

Read the following and then track what happens to it. The Evolution work
group encouraged the authors to develop much of it further though they
were not keen on all of it.

http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf

It is always more productive to work with like minded people than to set
out again from scratch.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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

jackklein@spamcop.net (Jack Klein) wrote:
> Proposal: typed enumerations.

> 2. Enumeration constants of such typed enumerations would have the
> type of the enumeration, example:

> Usefulness:
> 1. Interface (both languages).  Often system calls, third party
> libraries, and various other APIs are implemented with the caller
> passing a pointer (or perhaps a reference in C++) to one or more
> objects to be assigned.
>
> It would be beneficial to be able to do this:
>
> api_header.h:
> ----------
> typedef enum {
>   RECORD_FOUND,
>   RECORD_NOT_FOUND,
>   RECORD_BAD_QUERY,
>   RECORD_NO_DATABASE_OPEN
>  } query_result;
>
> record *query_database(const char *the_query, query_result *res);
>
> myapp.cpp:
> ----------
> void some_func(args)
> {
>   record *my_data;
>   query_result result;
>
>   my_data = query_database("some string", &result);
>   if (!my_data)
>   {
>     /* examine result code for reason for failure */
>     switch (result)
>     {
>       /* ... */
>     }
>   }
> }
>
> The problem with the second usage is that the library and the compiler
> may choose different underlying types for the query_result
> enumeration, especially if one is supplied as a pre-build library from
> a separate vendor.  The library code might use ints for all
> enumeration types, the application might used one of the character
> types because the values, 0 through 3, will fit in a character type.


Why not just convert the returned value into the appropriate enum type
before testing it?:

    void some_func(args)
    {
        record *      my_data;
        int           ires;
        query_result  result;

        my_data = query_database("some string", &ires);
        result = (enum query_result) ires;             //[A]

        switch (result)
        {
            case RECORD_FOUND:  ...;                   //[B]
            ...
        }
    }


Allowing the API library to use 'int*' for the returned status code is
about as portable as you can possibly get, even between C and C++, so
there is nothing inherently wrong with it.

-drt

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

jackklein@spamcop.net (Jack Klein) wrote:
> Proposal: typed enumerations.
>
> An enumeration definition will be allowed to include the name of any
> arithmetic type, example:
>
>   enum unsigned int ui { BIT_0 = 1, BIT_1 = 2 };
>   enum long double ld { PI = 3.14159 };
>
> Such typed enumeration definitions could be named or nameless.
>
> Such typed enumerations would have two features that current
> enumerations would not have:
>
> 1. Objects of such enumerations would specifically be of the defined
> type, example:
>
>   ui my_ui; /* C++ only */
>   enum ui my_ui; /* C or C++ */
>
> The object my_ui would be an unsigned int, as opposed the current
> enumerations where the implementation is free to select any integer
> type that can hold the values 1 and 2.


You can already force the type by using the limit macros:

    #include <limits.h>

    enum UnsignedLongValues
    {
        UL_A = ...,
        UL_B = ...,
        UL__MAX = ULONG_MAX
    };

-drt

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

At Mon, 26 Apr 2004 06:30:37 +0000 (UTC), jackklein@spamcop.net (Jack Klein) writes:

>   enum unsigned int ui { BIT_0 = 1, BIT_1 = 2 };

This would be a nice thing to add to C.  For example, I've had to
write C code like this:

    int array[] = { ... };
    enum {
      nelems = sizeof array / sizeof array[0],
      nelems_is_signed = -1
    };

The bogus 'nelems_is_signed' was needed simply because I wanted
'nelems' to be a signed integer constant equal to the number of
elements in 'array', and I wanted to avoid both casts and macros.

I suggest also adding this syntax:

   unsigned enum { BIT_0 = 1, BIT_1 = 2 };
   signed enum { BIT_0 = 1, BIT_1 = 2 };

Here the compiler would be free to choose the width, but not the
signedness, of the specified enum types.  This will fix the problem
that currently the value of the expression (BIT_0 < 0) is
implementation-defined, without overly constraining the implementation
of BIT_0.

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

jackklein@spamcop.net (Jack Klein) wrote:
> Proposal: typed enumerations.
>
> An enumeration definition will be allowed to include the name of any
> arithmetic type, example:
>
>   enum unsigned int ui { BIT_0 = 1, BIT_1 = 2 };
>   enum long double ld { PI = 3.14159 };

> 2. Definition of constants (primarily in C):
>
> C++ has largely eliminated the need for using macros to define
> constants of arithmetic type ...

Almost eliminated.  You still need macros (or something like them) for
conditional compilation, especially for code that must choose between
different implementation code for various target systems.

    #if CPU_BIG_ENDIAN
        ...code for big-endian architectures...
    #elif CPU_LITTLE_ENDIAN
        ...code for little-endian architectures...
    #else
        #error No support for middle-endian CPUs
    #endif

The need for this kind of code is not going to go away any time soon, and
C++ cannot cope with such needs with compiler constants alone, even as
powerful as their semantics are.


> ... by its specification of const qualified
> built-in objects defined at file/namespace scope to have internal
> linkage by default, and establishing the expectation that compilers
> will not actually create such objects if their address is not taken.

It's a QoI issue.  Most good compilers will not allocate space for constants
that are never used, or even for uses of them that can be inlined directly
in the code.

A case in point is the use of embedded revision numbers:

    static const char  REV[] =
        "@(#)src/foo.c $Revision: 1.2 $ $Date: 2004/04/25 15:30:00 $";

On many C++ compilers (notable MS Visual C++), this constant is optimized
away.  This is annoying, in this case, and so we must change it to the
slightly less robust:

    static char        REV[] =  ...;

The languages specifically allow compilers to eliminate constants, variables,
and even entire functions if it can determine that they are not used.  Many
good compilers do this fairly well.  Adding new semantics to the language(s)
won't force compiler writers to do a better job of optimizing.

Having written compilers before, I know that it's fairly easy to keep a flag
for each variable (and static function) to indicate whether it's been used
(including having its address taken) or not, and then to choose to skip
generating code for it if has not been used.  This kind of thing is typically
controlled by a compiler option.


> So this proposal will allow:
>   enum long double { PI=3.14159, E=2.71828 };
>
> ..to be functionally equivalent to:
>   const long double PI=3.14159;
>   const long double E=2.71828;
>
> ..in C++ and to:
>   #define PI 3.14159L
>   #define E  2.71828L
>
> ..in both languages.

Allowing non-integral types for enum types kind of flies in the face of the
term "enumeration", which implies discrete countable values, doesn't it?

I'm afraid I don't see the superiority of using an enum type over using a
const value.


--
On a completely different note, if you could force the compiler to provide
an array of name strings for a given enum type - now *that* would be useful.

    enum IOStatus
    {
        IO_OKAY,
        IO_READ_FAIL,
        IO_WRITE_FAIL,
        ...;

        const char * toString() const;     //[A]
    };

    void foo()
    {
        enum IOStatus   stat;

        stat = io_call(...);
        printf("I/O status: %s\n", stat.toString());   //[B]
        ...
    }

-drt

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

Jack Klein wrote:

> Proposal: typed enumerations.
>
> An enumeration definition will be allowed to include the name of any
> arithmetic type, example:
>
>   enum unsigned int ui { BIT_0 = 1, BIT_1 = 2 };
>   enum long double ld { PI = 3.14159 };

My first thought is that this is a misuse of the enumeration concept,
especially a floating type enumeration.  Are we implying that enum ld
can ONLY hold the value 3.14159L?

> api_header.h:
> ----------
> typedef enum {
>   RECORD_FOUND,
>   RECORD_NOT_FOUND,
>   RECORD_BAD_QUERY,
>   RECORD_NO_DATABASE_OPEN
>  } query_result;
>
> /* returns a pointer to the record if the query succeeds */
> /* or NULL if the query fails                            */
> record *query_database(const char *the_query, query_result *res);

> The problem with the second usage is that the library and the compiler
> may choose different underlying types for the query_result
> enumeration, especially if one is supplied as a pre-build library from
> a separate vendor.

This is simply a mismatch failure between the library and compiler.
There are many details for which the linkable library and compiled
application output must agree.  Compatible enum sizes is simply one of
them.  Why should we have to force the size of the enum when the
compiler should be able to choose an appropriate object type?  That the
compiler must choose the same type for the same declaration during both
the library compilation and application compilation is important, but
not a new type of requirement.

Thad

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

   That's a reasonable proposal.  Maybe.

   Wierdly, it has Pascal/Modula like declaration syntax:

 enum class Version : UINT8 { Ver1 = 1, Ver2 = 2 };

   The "name : type" syntax is very Pascal like.  I would
have expected

 enum class UINT8 Version { Ver1 = 1, Ver2 = 2 };

Is there a parsing problem with that?  Is there anywhere
else in C++ where we have "name : type"?  What's the
rationale for ":"?

(Actually, C++ probably should have had Pascal-type
declaration syntax.  Originally, C declaration syntax
was simple, but once typedefs and attributes came in, it
broke down.  What we have now is a context-dependent
parsing nightmare. But it's too late to fix.)

    Second, if we're going to have class-like enums,
derivation should be allowed.  There have been requests
for the ability to extend enum types.  If enum types
are to look like classes, that's a natural direction.

    Finally, there's still no way to get the first and
last (smallest and largest?) value of an enumeration.

   John Nagle
   Animats



Francis Glassborow wrote:

> In message <uobo80h2jappn129d4uk2u3duilp56jief@4ax.com>, Jack Klein
> <jackklein@spamcop.net> writes
>
>> I have long felt that the implementation of enumerations in both C and
>> C++, while different from each other, could be improved in a simple
>> way to provide greater utility.  I have used C-style casts, headers,
>> and pointers, rather than references, in the proposal since they are
>> common to both languages, not to slight the C++ features.
>
>
> Read the following and then track what happens to it. The Evolution work
> group encouraged the authors to develop much of it further though they
> were not keen on all of it.
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf
>
> It is always more productive to work with like minded people than to set
> out again from scratch.
>

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

Paul Eggert wrote:
> This would be a nice thing to add to C.  For example, I've had to
> write C code like this:
>
>     int array[] = { ... };
>     enum {
>       nelems = sizeof array / sizeof array[0],
>       nelems_is_signed = -1
>     };
>
> The bogus 'nelems_is_signed' was needed simply because I wanted
> 'nelems' to be a signed integer constant [...]

No it wasn't.  In C, the type of an enumeration constant is always int,
not the enumerated type.

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

David R Tribble wrote:
> You can already force the type by using the limit macros:
>
>     #include <limits.h>
>
>     enum UnsignedLongValues
>     {
>         UL_A = ...,
>         UL_B = ...,
>         UL__MAX = ULONG_MAX
>     };

Not in C:

     6.7.2.2 Enumeration specifiers

     Constraints

     2 The expression that defines the value of an enumeration constant
     shall be an integer constant expression that has a value
     representable as an int.

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

david@tribble.com (David R Tribble) writes:
> jackklein@spamcop.net (Jack Klein) wrote:
> > Proposal: typed enumerations.
[...]
> > 1. Objects of such enumerations would specifically be of the defined
> > type, example:
> >
> >   ui my_ui; /* C++ only */
> >   enum ui my_ui; /* C or C++ */
> >
> > The object my_ui would be an unsigned int, as opposed the current
> > enumerations where the implementation is free to select any integer
> > type that can hold the values 1 and 2.
>
>
> You can already force the type by using the limit macros:
>
>     #include <limits.h>
>
>     enum UnsignedLongValues
>     {
>         UL_A = ...,
>         UL_B = ...,
>         UL__MAX = ULONG_MAX
>     };

But then the implementation is still free to use a longer type.  For
example, given

    #include <limits.h>

    enum UCharValues {
        UC_A = ...,
        UC_B = ...,
        UC_MAX = UCHAR_MAX
    };

the compiler is likely to use type "int" or "unsigned int" to
represent the type, and it's certain (at least in C) that the literals
will be of type int.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

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

On Mon, 26 Apr 2004 18:31:05 +0000 (UTC), thadsmith@acm.org (Thad
Smith) wrote:

>Jack Klein wrote:
>
>> Proposal: typed enumerations.
>>
>> An enumeration definition will be allowed to include the name of any
>> arithmetic type, example:
>>
>>   enum unsigned int ui { BIT_0 = 1, BIT_1 = 2 };
>>   enum long double ld { PI = 3.14159 };
>
>My first thought is that this is a misuse of the enumeration concept,
>especially a floating type enumeration.  Are we implying that enum ld
>can ONLY hold the value 3.14159L?

IMHO, it fits well with the way I've seen enumerations used in
straight C.  After all, there's nothing for the compiler to complain
about in

   enum {RED, GREEN, BLUE} color;
   int magic;
   ...
   magic = GREEN;
   color = 42;

So enumerations are simply a way of declaring integral constants
(perhaps with implied values) and associated variables.  Jack's
proposal simply provides the programmer with a way to specify the
types of the constants and variables, expanding the horizon to include
all arithmetic types.

It seems C never really had a "concept" of enumerations, despite the
way "enum" is spelled.  Today the only difference between

   #define IDLE        0
   #define MANUAL      1
   #define AUTOMATIC   2

   unsigned char current_mode = IDLE;

and

   enum Mode {
      IDLE,
      MANUAL,
      AUTOMATIC
   } current_mode = IDLE;

is that, in the former, I must specify the mode values, and am able to
specify the variable type.  I the latter, I am able to specify the
mode values, but have to rely on the compiler to choose the variable
type.

To answer your original question, no, we're implying no such thing.
There's nothing wrong with

   long double otherld;
   ld = 2.7182818L;
   otherld = PI;

The biggest problem I see (from a usage rather than implementation
viewpoint) is being lured into a trap like

   if (ld == PI)  /*oops*/

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

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

On Mon, 26 Apr 2004 16:59:00 +0000 (UTC) in comp.std.c,
francis@robinton.demon.co.uk (Francis Glassborow) wrote:

>In message <uobo80h2jappn129d4uk2u3duilp56jief@4ax.com>, Jack Klein
><jackklein@spamcop.net> writes
>>I have long felt that the implementation of enumerations in both C and
>>C++, while different from each other, could be improved in a simple
>>way to provide greater utility.  I have used C-style casts, headers,
>>and pointers, rather than references, in the proposal since they are
>>common to both languages, not to slight the C++ features.
>
>Read the following and then track what happens to it. The Evolution work
>group encouraged the authors to develop much of it further though they
>were not keen on all of it.
>
>http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf
>
>It is always more productive to work with like minded people than to set
>out again from scratch.

Not really relevant to C as it relies on C++ inheritance and classes.
I'm suspicious about the exclusion of wchar_t as a base type: no
rationale is given (or I missed it), as character value enums are
useful, and could see wide character value enums also being useful.

--
Thanks. Take care, Brian Inglis  Calgary, Alberta, Canada

Brian.Inglis@CSi.com  (Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address  use address above to reply

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

On Mon, 26 Apr 2004 16:59:00 +0000 (UTC), francis@robinton.demon.co.uk
(Francis Glassborow) wrote in comp.std.c++:

> In message <uobo80h2jappn129d4uk2u3duilp56jief@4ax.com>, Jack Klein
> <jackklein@spamcop.net> writes
> >I have long felt that the implementation of enumerations in both C and
> >C++, while different from each other, could be improved in a simple
> >way to provide greater utility.  I have used C-style casts, headers,
> >and pointers, rather than references, in the proposal since they are
> >common to both languages, not to slight the C++ features.
>
> Read the following and then track what happens to it. The Evolution work
> group encouraged the authors to develop much of it further though they
> were not keen on all of it.
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf
>
> It is always more productive to work with like minded people than to set
> out again from scratch.

Francis, thanks very much for that link.  The C++ proposal has a lot
in it for C++ that is way beyond what I was proposing.  That may be
well and good for C++, but is out of the question as a feature for C.

Actually section 3.2 in the document, "Extend existing enums:
Underlying type and explicit scoping" is virtually identical to what I
proposed.  Other than the possible obstacle for the ':' in the
declaration, I would hope it would not be objectionable to the C
committee as well.

Even if C++ adopted the entire proposal, it would be good if C could
adopt 3.2 in a compatible way.

In fact, I'd be quite pleased if my proposal/section 3.2 made it into
C and C++ without the floating point types, just the integer types.

What I would like to be able to write (and I write quite a lot of code
like this, in embedded programming, with the large variety of
peripheral devices on uP's and DSP's today):

enum uint16_t /* pardon the C99'ism */
{
   RX_CHAR_AVAIL = 0x0001,
   TX_BUFFER_EMPTY = 0x0002,
   /* etc. */
};

extern uint16_t SCIStatusReg; /* mapped by linker magic */

if (SCIStatusReg & RX_CHAR_AVAIL)
{
   /* ... */
}

If I do this now, the compiler and static analysis tools will issue a
warning about using a signed int value in a bitwise operation.  I
could use a (uint1t_t) cast, but that only uglifies and obfuscates the
code.  There should be a simpler way.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

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

On Mon, 26 Apr 2004 17:41:49 +0000 (UTC), david@tribble.com (David R
Tribble) wrote in comp.std.c++:

> jackklein@spamcop.net (Jack Klein) wrote:
> > Proposal: typed enumerations.
>
> > 2. Enumeration constants of such typed enumerations would have the
> > type of the enumeration, example:
>
> > Usefulness:
> > 1. Interface (both languages).  Often system calls, third party
> > libraries, and various other APIs are implemented with the caller
> > passing a pointer (or perhaps a reference in C++) to one or more
> > objects to be assigned.
> >
> > It would be beneficial to be able to do this:
> >
> > api_header.h:
> > ----------
> > typedef enum {
> >   RECORD_FOUND,
> >   RECORD_NOT_FOUND,
> >   RECORD_BAD_QUERY,
> >   RECORD_NO_DATABASE_OPEN
> >  } query_result;
> >
> > record *query_database(const char *the_query, query_result *res);
> >
> > myapp.cpp:
> > ----------
> > void some_func(args)
> > {
> >   record *my_data;
> >   query_result result;
> >
> >   my_data = query_database("some string", &result);
> >   if (!my_data)
> >   {
> >     /* examine result code for reason for failure */
> >     switch (result)
> >     {
> >       /* ... */
> >     }
> >   }
> > }
> >
> > The problem with the second usage is that the library and the compiler
> > may choose different underlying types for the query_result
> > enumeration, especially if one is supplied as a pre-build library from
> > a separate vendor.  The library code might use ints for all
> > enumeration types, the application might used one of the character
> > types because the values, 0 through 3, will fit in a character type.
>
>
> Why not just convert the returned value into the appropriate enum type
> before testing it?:
>
>     void some_func(args)
>     {
>         record *      my_data;
>         int           ires;
>         query_result  result;
>
>         my_data = query_database("some string", &ires);
>         result = (enum query_result) ires;             //[A]
>
>         switch (result)
>         {
>             case RECORD_FOUND:  ...;                   //[B]
>             ...
>         }
>     }
>
>
> Allowing the API library to use 'int*' for the returned status code is
> about as portable as you can possibly get, even between C and C++, so
> there is nothing inherently wrong with it.
>
> -drt

Good point, but consider:

1.  Not all APIs (and system calls) are written in C or C++ at all.

2.  Casting is evil (and even worse, error prone) if it can be
avoided.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

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

Good morning, Francis Glassborow!

Francis Glassborow schrieb:

> In message <uobo80h2jappn129d4uk2u3duilp56jief@4ax.com>, Jack Klein=20
> <jackklein@spamcop.net> writes
>
>> I have long felt that the implementation of enumerations in both C and
>> C++, while different from each other, could be improved in a simple
>> way to provide greater utility.  I have used C-style casts, headers,
>> and pointers, rather than references, in the proposal since they are
>> common to both languages, not to slight the C++ features.
>
>
> Read the following and then track what happens to it. The Evolution=20
> work group encouraged the authors to develop much of it further though=20
> they were not keen on all of it.
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf
>
> It is always more productive to work with like minded people than to=20
> set out again from scratch.
>
Nice article! I happily realize, that despite my own simple-minded ideas=20
of such an enum extension
(which I discussed some months ago) there are honest steps toward a=20
well-designed concept.

Two points of criticism come to my mind:

1) I really don't see the advantage of floating-point types as=20
underlying type of enum classes. It also
constrasts to the usability of enum literals in ICE's, because we first=20
have to check, whether the
used enum-class fulfills the requirements modulo=20
static_cast<integer_type>(float_type_constant).

2) I would really appreciate the possibility for client code to **get**=20
the underlying integer type of an
existing enum (class), which would make 'delegation of dependencies'=20
much easier. The problem is, how
to realize such a requirement. The minimum possibility would be to allow=20
typedefs in enum classes
(which of course could be out-of-sync with the actual underlying type),=20
but I also could think of a
default-generated (implicit) typedef 'int_type' for such a beast. The=20
nice side-effect would be, that every
enum (class) could be used in combination with the std::numeric_limits=20
class template:

enum class E : int16_t {green, yellow, red, blue};
=2E
E::int_type i =3D ..;
int digits =3D std::numeric_limits<E::int_type>::digits;

What do you think?

Greetings from Bremen,

Daniel Kr=FCgler


=20

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

On Tue, 27 Apr 2004 03:15:20 +0000 (UTC) in comp.std.c,
jackklein@spamcop.net (Jack Klein) wrote:

>On Mon, 26 Apr 2004 16:59:00 +0000 (UTC), francis@robinton.demon.co.uk
>(Francis Glassborow) wrote in comp.std.c++:
>
>> In message <uobo80h2jappn129d4uk2u3duilp56jief@4ax.com>, Jack Klein
>> <jackklein@spamcop.net> writes
>> >I have long felt that the implementation of enumerations in both C and
>> >C++, while different from each other, could be improved in a simple
>> >way to provide greater utility.  I have used C-style casts, headers,
>> >and pointers, rather than references, in the proposal since they are
>> >common to both languages, not to slight the C++ features.
>>
>> Read the following and then track what happens to it. The Evolution work
>> group encouraged the authors to develop much of it further though they
>> were not keen on all of it.
>>
>> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1579.pdf
>>
>> It is always more productive to work with like minded people than to set
>> out again from scratch.
>
>Francis, thanks very much for that link.  The C++ proposal has a lot
>in it for C++ that is way beyond what I was proposing.  That may be
>well and good for C++, but is out of the question as a feature for C.
>
>Actually section 3.2 in the document, "Extend existing enums:
>Underlying type and explicit scoping" is virtually identical to what I
>proposed.  Other than the possible obstacle for the ':' in the
>declaration, I would hope it would not be objectionable to the C
>committee as well.
>
>Even if C++ adopted the entire proposal, it would be good if C could
>adopt 3.2 in a compatible way.
>
>In fact, I'd be quite pleased if my proposal/section 3.2 made it into
>C and C++ without the floating point types, just the integer types.

I'd like to see some rationale from Jack about reasons for including
floating point (and complex?) types. ISTM that providing floating
point enums conflicts with some of the facilities provided for better
floating point handling in C99.

I'd also like to see some rationale from Herb Sutter about reasons for
his C++ proposal including floating point (and complex?) types, and
excluding wchar_t.

>What I would like to be able to write (and I write quite a lot of code
>like this, in embedded programming, with the large variety of
>peripheral devices on uP's and DSP's today):
>
>enum uint16_t /* pardon the C99'ism */
>{
>   RX_CHAR_AVAIL = 0x0001,
>   TX_BUFFER_EMPTY = 0x0002,
>   /* etc. */
>};
>
>extern uint16_t SCIStatusReg; /* mapped by linker magic */
>
>if (SCIStatusReg & RX_CHAR_AVAIL)
>{
>   /* ... */
>}
>
>If I do this now, the compiler and static analysis tools will issue a
>warning about using a signed int value in a bitwise operation.  I
>could use a (uint1t_t) cast, but that only uglifies and obfuscates the
>code.  There should be a simpler way.

ISTM with this proposal enum becomes a type modifier, or might have to
be treated syntactically like a storage class. Grammarian comments?

--
Thanks. Take care, Brian Inglis  Calgary, Alberta, Canada

Brian.Inglis@CSi.com  (Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address  use address above to reply

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

In message <73lq805gq6nm6pqujatc0aulgvvgcn6umq@4ax.com>, Brian Inglis
<Brian.Inglis@SystematicSw.Invalid> writes
>Not really relevant to C as it relies on C++ inheritance and classes.

I agree, but the OP referred to both. WG21 members had reservations
about the syntax and some elements of the paper but it is only a
starting point for discussion. Part of the problem is that C++/CLI
requires some such mechanism and that syntax is the one currently
preferred by TC39/TG5.

In fact WG21 is not looking at enum class as any kind of class, it is
merely reusing a keyword as a descriminator from classic enum. If C
wished to provide a similar facility I think it could do so with the
same syntax and semantics.

>
>I'm suspicious about the exclusion of wchar_t as a base type: no
>rationale is given (or I missed it), as character value enums are
>useful, and could see wide character value enums also being useful.

So perhaps wchar_t will get re-instated. However note that that might be
a problem for C because it isn't a fundamental type in C.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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

In message <g0hr805b6e5nakklikm9eo341dmlpmtcvl@4ax.com>, Jack Klein
<jackklein@spamcop.net> writes
>Francis, thanks very much for that link.  The C++ proposal has a lot
>in it for C++ that is way beyond what I was proposing.  That may be
>well and good for C++, but is out of the question as a feature for C.

It is also beyond what the evolution work group in WG21 are comfortable
with. Note it is only the anchor paper from which WG21 will decide where
to go. However the parts you are interested in were well received in
Sydney. Perhaps those responsible for liaison (that includes me) with
WG14 need to bring it formally to the attention of WG14 (I think we
overlooked it in Sydney)



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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