 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
ch@chch.demon.co.uk
Guest
|
 Posted: Tue May 10, 2005 10:54 pm Post subject: Defect Report: permit final comma in enum (alignment with C) |
 |
|
[ forwarded to C++ Committee. -sdc ]
I expected I'd find this has already been raised, since I've seen
nresgroup articles mentioning this subject, but I cannot find it on any
of the DR lists, so here it is:
The C language (since C99), and some C++ compilers, accept:
enum { FOO, };
as syntactically valid. It would be useful
* for machine generated code
* for minimising changes when editing
* to allow a distinction between the final item being intended
as an ordinary item or as a limit:
enum { red, green, blue, num_colours }; // note no comma
enum { fred, jim, sheila, }; // last is not special
This proposed change is to permit a trailing comma in enum by adding:
enum identifier-opt { enumerator-list , }
to "Enumeration declarations" in 7.2 and to A.6 "enum-specifier".
--
Charles Bryant - [email]ch (AT) chch (DOT) demon.co.uk[/email]
[ 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: Wed May 11, 2005 8:59 pm Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
[email]ch (AT) chch (DOT) demon.co.uk[/email] wrote:
| Quote: | The C language (since C99), and some C++ compilers, accept:
enum { FOO, };
as syntactically valid. It would be useful
* for machine generated code
* for minimising changes when editing
* to allow a distinction between the final item being intended
as an ordinary item or as a limit:
enum { red, green, blue, num_colours }; // note no comma
enum { fred, jim, sheila, }; // last is not special
This proposed change is to permit a trailing comma in enum by adding:
enum identifier-opt { enumerator-list , }
to "Enumeration declarations" in 7.2 and to A.6 "enum-specifier".
|
Should this be extended to initializers?
int tab[] = { 1,2,3, };
Variable declarations?
int a,b,c,;
Function declarations?
void foo(bar,);
If not, why not?
This is probably a bad idea overall. The syntax has enough problems.
Actually, "derived enums" were a better idea.
enum t1(red, green, blue);
enum t2: public t1(orange, yellow, magenta);
John Nagle
---
[ 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 |
|
|
Andrei Alexandrescu
Guest
|
| Posted: Thu May 12, 2005 5:56 am Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
John Nagle wrote:
| Quote: | ch (AT) chch (DOT) demon.co.uk wrote:
This proposed change is to permit a trailing comma in enum by adding:
enum identifier-opt { enumerator-list , }
to "Enumeration declarations" in 7.2 and to A.6 "enum-specifier".
Should this be extended to initializers?
int tab[] = { 1,2,3, };
Variable declarations?
int a,b,c,;
Function declarations?
void foo(bar,);
If not, why not?
This is probably a bad idea overall. The syntax has enough problems.
|
Enumerated values and array initializer values are much more likely to
be machine-generated. Variable declarations and function argument
declarations, maybe less so.
I do think the proposal makes sense, and yes, array initializers already
allow the extra comma. Talk about setting one's own argument for failure
 ).
Allowing an extra comma in cases where it's desirable and doesn't add
ambiuguity doesn't IMHO add any problem to the syntax.
Andrei
---
[ 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 |
|
|
C. M. Heard
Guest
|
| Posted: Thu May 12, 2005 6:04 am Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
John Nagle wrote:
| Quote: | Charles Bryant wrote:
The C language (since C99), and some C++ compilers, accept:
enum { FOO, };
as syntactically valid. It would be useful
* for machine generated code
* for minimising changes when editing
* to allow a distinction between the final item being intended
as an ordinary item or as a limit:
enum { red, green, blue, num_colours }; // note no comma
enum { fred, jim, sheila, }; // last is not special
This proposed change is to permit a trailing comma in enum by adding:
enum identifier-opt { enumerator-list , }
to "Enumeration declarations" in 7.2 and to A.6 "enum-specifier".
Should this be extended to initializers?
int tab[] = { 1,2,3, };
|
The language already permits the trailing comma before the closing brace
in initializers, and it's very convenient. Allowing it there and not
in enum declarations is very arbitrary, and getting rid of that
arbitrariness would be a good thing. I also happen to agree with the
reasons already put forward by Mr Bryant.
Mike Heard
---
[ 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 |
|
|
Victor Bazarov
Guest
|
| Posted: Mon May 16, 2005 4:18 pm Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
John Nagle wrote:
| Quote: | [...]
Actually, "derived enums" were a better idea.
enum t1(red, green, blue);
enum t2: public t1(orange, yellow, magenta);
John Nagle
|
Why parentheses instead of curly braces? Why "public"? What does
it do? Would we also allow "private" and "protected"?
---
[ 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 |
|
|
Hyman Rosen
Guest
|
| Posted: Mon May 16, 2005 4:18 pm Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
John Nagle wrote:
| Quote: | Should this be extended to initializers?
int tab[] = { 1,2,3, };
|
Not only should it be, it already is! And it was that way in C, too.
See 8.5/1.
| Quote: | Variable declarations?
Function declarations?
If not, why not?
|
Because it is very common to extend lists of enumerators and initializers
but much less common to do so for the others. Although, I'll bet the Boost
preprocessor library authors and users would be much happier if these were
in fact allowed, so they wouldn't have to go through contortions to get rid
of final commas. So, yes, we should allow these too.
Another use is that when you break these up one per line, you can comment
out any line, or rearrange lines, without having to deal with the commas.
And another case where they should be allowed is in ctor init lists
X()::X() :
a(1),
b(2),
c(3),
{ }
for the same reasons.
| Quote: | Actually, "derived enums" were a better idea.
enum t1(red, green, blue);
enum t2: public t1(orange, yellow, magenta);
|
No they're not, because this "derivation" works in exactly the opposite sense of
class derivation. All t1s are t2s, but not all t2s are t1s.
---
[ 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 |
|
|
Charles Bryant
Guest
|
| Posted: Mon May 16, 2005 4:20 pm Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
In article <rNgge.1123$3%4.205 (AT) newssvr13 (DOT) news.prodigy.com>,
John Nagle <nagle (AT) animats (DOT) com> wrote:
| Quote: | ch (AT) chch (DOT) demon.co.uk wrote:
This proposed change is to permit a trailing comma in enum by adding:
enum identifier-opt { enumerator-list , }
to "Enumeration declarations" in 7.2 and to A.6 "enum-specifier".
Should this be extended to initializers?
int tab[] = { 1,2,3, };
Variable declarations?
int a,b,c,;
|
That would be nice.
| Quote: | Function declarations?
void foo(bar,);
|
That too. And function calls:
foo(1, 2,);
Such proposals are less attractive since they are neither already common
practice nor differences between C and C++.
If we're considering true extensions, I'd like a trailing comma after
the last initialiser in an constructor's initialiser list:
Foo(int x) : a_(x), b_(0), { }
This is particularly useful for:
class Foo {
#ifdef DBG_FOO_OPCOUNT
int opcount_;
#endif
int x_;
public:
Foo() : x_(0),
#ifdef DBG_FOO_OPCOUNT
opcount_(0),
#endif
{ }
It would also be very handy when editing code, as adding or deleting
a member wouldn't require modifying the adjacent initialiser. Of course,
the empty case would also be nice:
Foo() : { }
as this is otherwise a special case.
These are all essentially the same idea and probably very familiar to
people who leared Pascal and C and were annoyed at:
IF condition THEN
x := 2
END;
but:
IF condition THEN
BEGIN
x := 2;
y := 2
END
END;
Note how the semicolon mus be added even though the assignment to x is
not changing.
---
[ 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 |
|
|
ThosRTanner
Guest
|
| Posted: Mon May 16, 2005 5:19 pm Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
[email]ch (AT) chch (DOT) demon.co.uk[/email] wrote:
| Quote: | [ forwarded to C++ Committee. -sdc ]
I expected I'd find this has already been raised, since I've seen
nresgroup articles mentioning this subject, but I cannot find it on
any
of the DR lists, so here it is:
The C language (since C99), and some C++ compilers, accept:
enum { FOO, };
as syntactically valid. It would be useful
* for machine generated code
Why? It is easy for machine generated code to not generate a comma for |
the last item in a list. It has to do it anyway for parameter lists,
structure members, and even etceteras.
| Quote: | * for minimising changes when editing
So, instead of adding an enum member by typing ", fred", you add it by |
typing "fred, ". That doesn't, to my mind, do much to minimise changes.
| Quote: | * to allow a distinction between the final item being intended
as an ordinary item or as a limit:
enum { red, green, blue, num_colours }; // note no comma
enum { fred, jim, sheila, }; // last is not special
That is highly open to mistakes. A comment "//This MUST be last" is |
much clearer - a single comma can easily be missed. I'd prefer an
extension to enums which allowed 'min' and 'max' properties for the
type. (Something a bit like numeric_limits<enum name> automatically
generated by the compiler).
Tom
---
[ 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: Tue May 17, 2005 11:57 pm Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
Hyman Rosen wrote:
| Quote: | John Nagle wrote:
Variable declarations?
Function declarations?
If not, why not?
Because it is very common to extend lists of enumerators and initializers
but much less common to do so for the others. Although, I'll bet the Boost
preprocessor library authors and users would be much happier if these were
in fact allowed, so they wouldn't have to go through contortions to get rid
of final commas. So, yes, we should allow these too.
|
Remember the discussion of the "whitespace operator?"
| Quote: | Actually, "derived enums" were a better idea.
enum t1(red, green, blue);
enum t2: public t1(orange, yellow, magenta);
No they're not, because this "derivation" works in exactly the opposite
sense of
class derivation. All t1s are t2s, but not all t2s are t1s.
|
True. Maybe we should have "virtual enums", which
can be extended:
virtual enum t1{red, green, blue};
enum t2: t1{orange, yellow, magenta};
But that runs into the problem
virtual enum t1{red, green, blue};
enum t2: t1{orange, yellow, magenta};
enum t3: t1{teal, puce, lavender};
which could lead to ambiguous assignment of enum values.
So that probably won't work.
John Nagle
---
[ 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 |
|
|
Andrei Alexandrescu
Guest
|
| Posted: Wed May 18, 2005 12:05 am Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
ThosRTanner wrote:
| Quote: | Why? It is easy for machine generated code to not generate a comma for
the last item in a list. It has to do it anyway for parameter lists,
structure members, and even etceteras.
|
The point is, which code is routinely machine generated? Enum values and
array members are generated way more often than the other entities
mentioned.
| Quote: | * for minimising changes when editing
So, instead of adding an enum member by typing ", fred", you add it by
typing "fred, ". That doesn't, to my mind, do much to minimise changes.
|
How about the first item then. The point is, terminators are easier to
manage than separators. The gist of your argument is that comma as a
terminator is a tad awkward on the eye, which I think many would agree
with. But there are advantages to it, and if you don't like it, don't
put it there. It's entirely innocuous.
| Quote: | * to allow a distinction between the final item being intended
as an ordinary item or as a limit:
enum { red, green, blue, num_colours }; // note no comma
enum { fred, jim, sheila, }; // last is not special
That is highly open to mistakes. A comment "//This MUST be last" is
much clearer - a single comma can easily be missed. I'd prefer an
extension to enums which allowed 'min' and 'max' properties for the
type. (Something a bit like numeric_limits<enum name> automatically
generated by the compiler).
|
That I'd like. Including numeric_limits<my_enum>::ends_in_a_comma().
:oD
Andrei
---
[ 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 |
|
|
Andrei Alexandrescu
Guest
|
| Posted: Wed May 18, 2005 5:40 am Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
John Nagle wrote:
| Quote: | True. Maybe we should have "virtual enums", which
can be extended:
virtual enum t1{red, green, blue};
enum t2: t1{orange, yellow, magenta};
But that runs into the problem
virtual enum t1{red, green, blue};
enum t2: t1{orange, yellow, magenta};
enum t3: t1{teal, puce, lavender};
which could lead to ambiguous assignment of enum values.
So that probably won't work.
|
This whole "inheritance means extension" idea is a fallacy. Inheritance
is the opposite of extension. A dynamically polymorphic type must be
understood as the transitive closure of all possible types that inherit
it, and as such it is the most general. Any inheritance relationship is
a subset operation - it draws from a more general set a more specialized
set.
Enum extensions as discussed about would require a different
understanding of inheritance and as such would confuse the heck out of
everybody and their pet.
Andrei
---
[ 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 |
|
|
ThosRTanner
Guest
|
| Posted: Thu May 19, 2005 4:10 am Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
"Andrei Alexandrescu See Website For Email wrote:
| Quote: | ThosRTanner wrote:
Why? It is easy for machine generated code to not generate a comma
for
the last item in a list. It has to do it anyway for parameter
lists,
structure members, and even etceteras.
The point is, which code is routinely machine generated? Enum values
and
array members are generated way more often than the other entities
mentioned.
It depends what you are using for generating what I suppose. In my |
experience, parameter lists have been generated more often than enum
values.
I just find the "easier for machine generated code" slightly risible.
All that code to generate the list, and the one extra line necessary to
not output a comma at the end of the list?
| Quote: | * for minimising changes when editing
So, instead of adding an enum member by typing ", fred", you add it
by
typing "fred, ". That doesn't, to my mind, do much to minimise
changes.
How about the first item then. The point is, terminators are easier
to
manage than separators. The gist of your argument is that comma as a
terminator is a tad awkward on the eye, which I think many would
agree
with. But there are advantages to it, and if you don't like it, don't
put it there. It's entirely innocuous.
I just don't think the arguments for allowing it are particularly |
overwhelming. There are other things I think would be better for the
language.
| Quote: | * to allow a distinction between the final item being intended
as an ordinary item or as a limit:
enum { red, green, blue, num_colours }; // note no comma
enum { fred, jim, sheila, }; // last is not special
That is highly open to mistakes. A comment "//This MUST be last" is
much clearer - a single comma can easily be missed. I'd prefer an
extension to enums which allowed 'min' and 'max' properties for the
type. (Something a bit like numeric_limits<enum name> automatically
generated by the compiler).
That I'd like. Including numeric_limits<my_enum>::ends_in_a_comma().
D
I was thinking about |
enum { r, g, b } colours;
int num_colours = numeric_limits<colours>.max() -
numeric_limits<colours>.min() + 1;
But I could live with your function as well!
---
[ 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 |
|
|
Andrei Alexandrescu (See
Guest
|
| Posted: Thu May 19, 2005 6:40 am Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
ThosRTanner wrote:
| Quote: | It depends what you are using for generating what I suppose. In my
experience, parameter lists have been generated more often than enum
values.
I just find the "easier for machine generated code" slightly risible.
All that code to generate the list, and the one extra line necessary to
not output a comma at the end of the list?
|
Well, "slightly risible" is very nice ). To be "mildly unforgiving":
In the experience of many others, values are machine-generated, not
parameter lists. Proof? Arrays allow the extra comma ).
The code could be generated with a primitive tool such as sed, grep,
cut, or even find. In some cases it's not a really really big deal to
avoid the terminating comma, but it sure is easier for those tools if
C++ allowed it. In my enum-generating scripts I always need to pay
special attention to that. What I often do is put one extra "dummy"
value in the C++ handwritten part, just to take care of the darn comma.
Andrei
---
[ 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 |
|
|
C. M. Heard
Guest
|
| Posted: Thu May 19, 2005 8:32 pm Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
Charles Bryant wrote:
| Quote: | These are all essentially the same idea and probably very familiar to
people who leared Pascal and C and were annoyed at:
IF condition THEN
x := 2
END;
but:
IF condition THEN
BEGIN
x := 2;
y := 2
END
END;
Note how the semicolon mus be added even though the assignment to x is
not changing.
|
Yes, and Pascal handled that properly, by allowing a trailing semicolon
after the last statement (in the actual grammar this was a null statement).
Thus one could one to write
IF condition
THEN BEGIN
x := 2;
END;
and
IF condition
THEN BEGIN
x := 2;
y := 2;
END;
It was not uncommon to see this recommended in coding standards.
//cmh
---
[ 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 |
|
|
Andrei Alexandrescu
Guest
|
| Posted: Fri May 20, 2005 4:12 am Post subject: Re: Defect Report: permit final comma in enum (alignment wit |
|
|
C. M. Heard wrote:
| Quote: | Charles Bryant wrote:
These are all essentially the same idea and probably very familiar to
people who leared Pascal and C and were annoyed at:
IF condition THEN
x := 2
END;
but:
IF condition THEN
BEGIN
x := 2;
y := 2
END
END;
Note how the semicolon mus be added even though the assignment to x is
not changing.
Yes, and Pascal handled that properly, by allowing a trailing semicolon
after the last statement (in the actual grammar this was a null statement).
Thus one could one to write
IF condition
THEN BEGIN
x := 2;
END;
and
IF condition
THEN BEGIN
x := 2;
y := 2;
END;
It was not uncommon to see this recommended in coding standards.
|
Except, of course, for the case an else would follow an if, in which
case the semicolon MUST not be there.
Gotta love Pascal ).
Andrei
---
[ 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
