AllanW@my-dejanews.com wrote:
>
> In article <m3iucw0xds.fsf@gabi-soft.fr>,
>   kanze@gabi-soft.fr (J. Kanze) wrote:
> > sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) writes:
> >
> > |>  On 19 Feb 99 14:11:35 GMT, Thomas Hadig <hadig@rwth-aachen.de> wrote:
> > |>
> > |>  >I am missing a (simple to workaround) feature C++, that is there is no
> > |>  >post/pre-in/de-crement operator for enumerations defined, i.e.
> > |>
> > |>  There is an implicit conversion of enum to unsigned/signed int.
> > |>  Then operarator++ applies to the returned integer.
> >
> > Either I'm missing something, or the result of the implicit conversion
> > is not an lvalue, and ++ cannot be applied to it.
>
> What should ++ do with the argument matches the highest enumeration
> constant, but not the highest possible value in the underlying type?

The result is unspecified (or undefined?)

The result of

int i=INT_MAX;
++i;

is AFAIK unspecified or undefined as well. So there's precedent.

> What should ++ do when the argument matches some other enumeration
> constant, but the next possible integral value doesn't?

++e should be exactly equivalent to e=E(e+1), where e is of
the enumeration type E. The expression e=E(e+1) already has a
specified meaning. The expression e++ is then simple to
specify.

> (How should
> the run-time code even detect this without being bloated and slow?)

Why should the run-time code try to detect it at all?
It doesn't detect integer overflows and index overflows;
on some systems floating point overflows are not detected,
but result in NaN values. Dereferencing null pointers is
not always detected (only on systems with hardware memory
protection, you usually get them detected). Why should
the enum be treated differently? After all, it's not
any more high-level than all the other cases (and even
then, most container/iterator operations are not checked
either). Of course an implementation _may_ try to detect it,
f.ex. in a special debug mode. But it is not required to do
so.

> What should ++ do with the argument has the higest possible value
> in the underlying type?

That can happen while working with the underlying type as well.

>
> If you can answer all three of those questions, then it's easy for
> you to write your own operator++. For instance
>
>   #include <iostream>
>
>   enum colors {
>       black, brown, red, orange, yellow,
>       green, blue, violet, grey, gray=grey, white
>   };
>   // Increment operators. Notice these are trivial to write.
>   colors&operator++(colors&c) { c = colors(c+1); return c; }
>   colors operator++(colors&c,int) { colors r(c); ++c; return r; }

Well, the original poster already stated that it's easy to
work around. The question was, why the standard doesn't
generate it in the first place.

One possible answer is that one might sometimes want a
slightly different behaviour:

enum Direction { north, east, south, west };

Direction& operator++(Direction& d)
{
  return d=(d==west? north : Direction(d+1));
}
// and the other operators accordingly).

[...]


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Thomas Hadig <hadig@rwth-aachen.de> wrote:
>> I am missing a (simple to workaround) feature C++, that is there is
>> no post/pre-in/de-crement operator for enumerations defined, i.e.
...

Siemel Naran wrote:
> There is an implicit conversion of enum to unsigned/signed int.
> Then operarator++ applies to the returned integer.
> Same holds for operator| and so on.
>
> IMHO, this sucks.
> There should no conversion from enum to integer.

If there were no implicit conversion of enums to ints, and if you
wanted to convert an enum to an int, which type would you use?
I.e., how would you know the size of the enum type?  (This question
came up in another thread.)

Allowing the compiler to do implicit enum->int conversions has
the benefit of letting the compiler worry about the size of the
converted integer result so you don't have to.

-- David R. Tribble, dtribble@technologist.com --


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi folks,

i am new to this news group, so maybe this is a FAQ, i did not find.

 [Moderator's note: this question has come up before, but
 not often enough for anyone to add an entry for it to the
 comp.std.c++ FAQ list, which is available via the URL
 at the end of this message.  If someone feels the urge
 to write up good, concise answer to this question for
 the FAQ list, I'm sure Matt Austern would be happy to
 include it there.  Same goes for any other commonly asked
 question.  -moderator (fjh).]

I am missing a (simple to workaround) feature C++, that is there is no
post/pre-in/de-crement operator for enumerations defined, i.e.
enum color { red, green, blue };
color c=red;
c++;
does lead to a compiler error/warning.

Is there a special reason for omitting the operators or could it be added
to the standard ?

[I see some reasons, why such an operator might be disfavored:
 - c++ looks like a successor function, which is not true for
   enum color { red=1, green=3, blue=5};
   since "red"++ would not be equal green
 - these operators might lead to illegal values (see above example)
 However both problems also occur in the c=c+1 case, so i do not see
 too big a problem in that point]

Ciao
Thomas

----------------------------------------------------------------------------
Thomas Hadig, Ottensen, Donnerstr. 20, D-22763 Hamburg    (+49 40 39901186)
  office : I. Phys. Institut AAC, Room 1c354, Notkestr. 85, D-22603 Hamburg
           hadig@rwth-aachen.de                      Tel.  +49 40 8998 2312
http://www-h1.desy.de/~hadig/
----------------------------------------------------------------------------
In a world without walls and fences, who needs windows and gates ?
----------------------------------------------------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 19 Feb 99 14:11:35 GMT, Thomas Hadig <hadig@rwth-aachen.de> wrote:

>I am missing a (simple to workaround) feature C++, that is there is no
>post/pre-in/de-crement operator for enumerations defined, i.e.

There is an implicit conversion of enum to unsigned/signed int.
Then operarator++ applies to the returned integer.
Same holds for operator| and so on.
IMHO, this sucks.
There should no conversion from enum to integer.


>enum color { red, green, blue };
>color c=red;
>c++;
>does lead to a compiler error/warning.

There is an advanced feature of C++ called enum operator overloading.

inline color& operator++(color& c)
{
   return c=color(unsigned(c)+1)%3u);
}

----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36CD3F64.3531884C@rwth-aachen.de>, Thomas Hadig <hadig@rwth-
aachen.de> writes
>I am missing a (simple to workaround) feature C++, that is there is no
>post/pre-in/de-crement operator for enumerations defined, i.e.
>enum color { red, green, blue };
>color c=red;
>c++;
>does lead to a compiler error/warning.
>
>Is there a special reason for omitting the operators or could it be added
>to the standard ?
>
>[I see some reasons, why such an operator might be disfavored:
> - c++ looks like a successor function, which is not true for
>   enum color { red=1, green=3, blue=5};
>   since "red"++ would not be equal green
> - these operators might lead to illegal values (see above example)
> However both problems also occur in the c=c+1 case, so i do not see
> too big a problem in that point]

But c=c+1; is, I believe also an error.  There are implicit conversions
from enums to ints but not the other way so you must write:

c = color(c+1);


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) writes:

|>  On 19 Feb 99 14:11:35 GMT, Thomas Hadig <hadig@rwth-aachen.de> wrote:
|>
|>  >I am missing a (simple to workaround) feature C++, that is there is no
|>  >post/pre-in/de-crement operator for enumerations defined, i.e.
|>
|>  There is an implicit conversion of enum to unsigned/signed int.
|>  Then operarator++ applies to the returned integer.

Either I'm missing something, or the result of the implicit conversion
is not an lvalue, and ++ cannot be applied to it.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <m3iucw0xds.fsf@gabi-soft.fr>,
  kanze@gabi-soft.fr (J. Kanze) wrote:
> sbnaran@fermi.ceg.uiuc.edu (Siemel Naran) writes:
>
> |>  On 19 Feb 99 14:11:35 GMT, Thomas Hadig <hadig@rwth-aachen.de> wrote:
> |>
> |>  >I am missing a (simple to workaround) feature C++, that is there is no
> |>  >post/pre-in/de-crement operator for enumerations defined, i.e.
> |>
> |>  There is an implicit conversion of enum to unsigned/signed int.
> |>  Then operarator++ applies to the returned integer.
>
> Either I'm missing something, or the result of the implicit conversion
> is not an lvalue, and ++ cannot be applied to it.

What should ++ do with the argument matches the highest enumeration
constant, but not the highest possible value in the underlying type?
What should ++ do when the argument matches some other enumeration
constant, but the next possible integral value doesn't? (How should
the run-time code even detect this without being bloated and slow?)
What should ++ do with the argument has the higest possible value
in the underlying type?

If you can answer all three of those questions, then it's easy for
you to write your own operator++. For instance

  #include <iostream>

  enum colors {
      black, brown, red, orange, yellow,
      green, blue, violet, grey, gray=grey, white
  };
  // Increment operators. Notice these are trivial to write.
  colors&operator++(colors&c) { c = colors(c+1); return c; }
  colors operator++(colors&c,int) { colors r(c); ++c; return r; }

  // Operator<<. Not needed for operator++, used for exposition only
  std::ostream&operator<<(std::ostream&o,const colors&c) {
    switch(c) {
      case black:  o<<"Black";                 break;
      case brown:  o<<"Brown";                 break;
      case red:    o<<"Red";                   break;
      case orange: o<<"Orange";                break;
      case yellow: o<<"Yellow";                break;
      case green:  o<<"Green";                 break;
      case blue:   o<<"Blue";                  break;
      case violet: o<<"Violet";                break;
      case grey:   o<<"Grey";                  break;
      case white:  o<<"White";                 break;
      default:     o<<"colors("<<long(c)<<")"; break;
    }
    return o;
  }

  int main() {
    for (colors x = black; x<=white; ++x)
      std::cout << x << ' ';
    std::cout << std::endl;
    return 0;
  }
  // Result:
  // Black Brown Red Orange Yellow Green Blue Violet Grey White
  // then assert failure (if enabled)
  // caused by trying to increment from white...

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]