[ 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 - ch@chch.demon.co.uk



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

ch@chch.demon.co.uk 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, };

     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                       ]

John Nagle wrote:
> ch@chch.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
:o).

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                       ]

John Nagle wrote:
>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                       ]

John Nagle wrote:
> [...]
> 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                       ]

John Nagle wrote:
>     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.

>     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.

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

ch@chch.demon.co.uk wrote:
> [ 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.

>  * 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.

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

In article <rNgge.1123$3%4.205@newssvr13.news.prodigy.com>,
John Nagle <nagle@animats.com> wrote:
>ch@chch.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.

>     Function declarations?
>
> void foo(bar,);

That too. And function calls:
 foo(1, 2,);

>     If not, why not?

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                       ]

Hyman Rosen wrote:

> 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?"

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

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.

>> * 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.

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

John Nagle wrote:
>    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                       ]

"Andrei Alexandrescu See Website For Email wrote:
> 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?

> >> * 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.

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

ThosRTanner wrote:
> 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 :o). To be "mildly unforgiving":
In the experience of many others, values are machine-generated, not
parameter lists. Proof? Arrays allow the extra comma :o).

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                       ]

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.

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

C. M. Heard wrote:
> 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 :o).

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                       ]

""Andrei Alexandrescu (See Website For Email)""
<SeeWebsiteForEmail@moderncppdesign.com> wrote in message
news:IGLtJK.1JGn@beaver.cs.washington.edu...
> 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.
>
>>> * 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.
>
>>> * 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().

This is a awfully small tail wagging the C++ dog(IMO that is). Certainly
this could/should handled by a library rather than a core language change.
The problem is more that the ostream_iterators are pretty lame in this
regard. The following code addresses the issue consistently for all
streaming of delimited data.

    ...

    #include <RangeStreamer.h>

    std::ofstream code( ... );

    code << range_stream( an_enum.begin()
                        , an_enum.end()
                        , "enum somename \n{ " // begin delim
                        , "\n, "               // inner delim
                        , "\n};"               // end   delim
                        );

With the definition shown below. IIRC, Johathan Turkanis proffered a much
more extensive facility at boost not too long ago. I think the library
addition was turned down because many thought this was a solution to a
non-problem.

Jeff Flinn


#if !defined(RangeStreamerHeaderIncluded)
    #define  RangeStreamerHeaderIncluded

template< class tItr, class tDBeg, class tDInner, class tDEnd > class
range_streamer
{
   tItr    mBeg;
   tItr    mEnd;
   tDBeg   mDBeg;
   tDInner mDInner;
   tDEnd   mDEnd;
public:
   range_streamer( tItr aBeg, tItr aEnd, tDBeg aDBeg, tDInner aDInner, tDEnd
aDEnd )
   : mBeg   ( aBeg    )
   , mEnd   ( aEnd    )
   , mDBeg  ( aDBeg   )
   , mDInner( aDInner )
   , mDEnd  ( aDEnd   )
   {}

   template< class tStream >
   void OutputTo( tStream& s )const
   {
      if( mBeg != mEnd )
      {
         tItr lItr = mBeg;

         s << mDBeg << *lItr;

         for( ++lItr ; lItr != mEnd ; ++lItr )
         {
            s << mDInner << *lItr;
         }
         s << mDEnd;
      }
   }
};

template< class tItr, class tDBeg, class tDInner, class tDEnd >
inline range_streamer<tItr,tDBeg,tDInner,tDEnd>
range_stream( tItr aBeg, tItr aEnd, tDBeg aDBeg, tDInner aDInner, tDEnd
aDEnd )
{
   return range_streamer<tItr,tDBeg,tDInner,tDEnd>( aBeg, aEnd, aDBeg,
aDInner, aDEnd );
}

template< class tStream, class tItr, class tDBeg, class tDInner, class tDEnd
 >
inline tStream& operator<<( tStream& s, const
range_streamer<tItr,tDBeg,tDInner,tDEnd>& aRS )
{
   aRS.OutputTo(s);

   return s;
}

#endif //RangeStreamerHeaderIncluded


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

Jeff Flinn wrote:
> ""Andrei Alexandrescu (See Website For Email)""
[snip]
> This is a awfully small tail wagging the C++ dog(IMO that is). Certainly
> this could/should handled by a library rather than a core language change.
> The problem is more that the ostream_iterators are pretty lame in this
> regard. The following code addresses the issue consistently for all
> streaming of delimited data.

[snip C++ code printing an enum...]

I'm not sure why that was posted in reply to my post, and not sure the
whole message pertains to the topic at all.

We were talking about values generated by external programs (text
manipulation tools) and that are part of the input to the C++ compiler.
The code posted shows some nice facility for printing out enums from
within C++, which is a completely different subject. I'm sure everybody
here knows how to print a comma-separated or
comma-separated-and-terminated list of values in C++, and if that's
often done, a library is helpful, but...?!?


Cheers,

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                       ]