 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Jack Klein
Guest
|
 Posted: Mon Apr 26, 2004 6:30 am Post subject: Proposal for new feature in both C and C++ |
 |
|
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
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 ]
|
|
| Back to top |
|
 |
Francis Glassborow
Guest
|
| Posted: Mon Apr 26, 2004 4:59 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
In message <uobo80h2jappn129d4uk2u3duilp56jief (AT) 4ax (DOT) com>, Jack Klein
<jackklein (AT) spamcop (DOT) net> writes
| Quote: | 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 ]
|
|
| Back to top |
|
|
David R Tribble
Guest
|
| Posted: Mon Apr 26, 2004 5:41 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
[email]jackklein (AT) spamcop (DOT) net[/email] (Jack Klein) wrote:
| Quote: | 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 ]
|
|
| Back to top |
|
|
David R Tribble
Guest
|
| Posted: Mon Apr 26, 2004 5:41 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
[email]jackklein (AT) spamcop (DOT) net[/email] (Jack Klein) wrote:
| Quote: | 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 ]
|
|
| Back to top |
|
|
Paul Eggert
Guest
|
| Posted: Mon Apr 26, 2004 6:18 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
At Mon, 26 Apr 2004 06:30:37 +0000 (UTC), [email]jackklein (AT) spamcop (DOT) net[/email] (Jack Klein) writes:
| Quote: | 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 ]
|
|
| Back to top |
|
|
David R Tribble
Guest
|
| Posted: Mon Apr 26, 2004 6:30 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
[email]jackklein (AT) spamcop (DOT) net[/email] (Jack Klein) wrote:
| Quote: | 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.
| Quote: | ... 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.
| Quote: | 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: %sn", 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 ]
|
|
| Back to top |
|
|
Thad Smith
Guest
|
| Posted: Mon Apr 26, 2004 6:31 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
Jack Klein wrote:
| Quote: | 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?
| Quote: | 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 ]
|
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Mon Apr 26, 2004 6:31 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
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:
| Quote: | In message <uobo80h2jappn129d4uk2u3duilp56jief (AT) 4ax (DOT) com>, Jack Klein
[email]jackklein (AT) spamcop (DOT) net[/email]> 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 ]
|
|
| Back to top |
|
|
Wojtek Lerch
Guest
|
| Posted: Mon Apr 26, 2004 8:36 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
Paul Eggert wrote:
| Quote: | 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 ]
|
|
| Back to top |
|
|
Wojtek Lerch
Guest
|
| Posted: Mon Apr 26, 2004 8:57 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
David R Tribble wrote:
| Quote: | You can already force the type by using the limit macros:
#include
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 ]
|
|
| Back to top |
|
|
Keith Thompson
Guest
|
| Posted: Mon Apr 26, 2004 8:57 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
[email]david (AT) tribble (DOT) com[/email] (David R Tribble) writes:
| Quote: | jackklein (AT) spamcop (DOT) 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
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) [email]kst-u (AT) mib (DOT) org[/email] <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 ]
|
|
| Back to top |
|
|
Dave Hansen
Guest
|
| Posted: Mon Apr 26, 2004 9:37 pm Post subject: Re: Proposal for new feature in both C and C++ |
|
|
On Mon, 26 Apr 2004 18:31:05 +0000 (UTC), [email]thadsmith (AT) acm (DOT) org[/email] (Thad
Smith) wrote:
| Quote: | 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 ]
|
|
| Back to top |
|
|
Brian Inglis
Guest
|
| Posted: Tue Apr 27, 2004 1:42 am Post subject: Re: Proposal for new feature in both C and C++ |
|
|
On Mon, 26 Apr 2004 16:59:00 +0000 (UTC) in comp.std.c,
[email]francis (AT) robinton (DOT) demon.co.uk[/email] (Francis Glassborow) wrote:
| Quote: | In message <uobo80h2jappn129d4uk2u3duilp56jief (AT) 4ax (DOT) com>, Jack Klein
[email]jackklein (AT) spamcop (DOT) net[/email]> 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
[email]Brian.Inglis (AT) CSi (DOT) com[/email] (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 ]
|
|
| Back to top |
|
|
Jack Klein
Guest
|
| Posted: Tue Apr 27, 2004 3:15 am Post subject: Re: Proposal for new feature in both C and C++ |
|
|
On Mon, 26 Apr 2004 16:59:00 +0000 (UTC), [email]francis (AT) robinton (DOT) demon.co.uk[/email]
(Francis Glassborow) wrote in comp.std.c++:
| Quote: | In message <uobo80h2jappn129d4uk2u3duilp56jief (AT) 4ax (DOT) com>, Jack Klein
[email]jackklein (AT) spamcop (DOT) net[/email]> 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 ]
|
|
| Back to top |
|
|
Jack Klein
Guest
|
| Posted: Tue Apr 27, 2004 4:44 am Post subject: Re: Proposal for new feature in both C and C++ |
|
|
On Mon, 26 Apr 2004 17:41:49 +0000 (UTC), [email]david (AT) tribble (DOT) com[/email] (David R
Tribble) wrote in comp.std.c++:
| Quote: | jackklein (AT) spamcop (DOT) 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 ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
