Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Incrimenting enum type in MS VS 2015

36 views
Skip to first unread message

Bob Langelaan

unread,
Feb 28, 2016, 2:39:13 PM2/28/16
to
I have defined a variable m_Dir of the type:

enum Directions { NORTH, EAST, SOUTH, WEST };

I thought I should be able to increment the variable:

++m_Dir;

but I get the error:

"Error (active) this operation on an enumerated type requires an applicable user-defined operator function"

I thought this was supposed to work. Is this a bug or am I remembering wrong?

Thanks,
Bob

JiiPee

unread,
Feb 28, 2016, 4:23:46 PM2/28/16
to
On 28/02/2016 19:38, Bob Langelaan wrote:
> enum Directions { NORTH, EAST, SOUTH, WEST };

you can do something like this:
Directions kk = NORTH;
kk = (Directions)(kk + 1);

Vir Campestris

unread,
Feb 28, 2016, 4:44:06 PM2/28/16
to
On 28/02/2016 19:38, Bob Langelaan wrote:
IIRC it works in C.

When you increment an enum you get an int (usually) - the underlying
type for an enum. You then have to cast it back to the enum type - as
JiiPee showed - or you can make an operator++ function for the enum type.

Directions operator++(const Directions old)
{
if (Direction == WEST)
return North;
else
return static_cast<Directions>(++old);
}

(and I haven't even fed that to a compiler so it's probably wrong)

Andy

Victor Bazarov

unread,
Feb 28, 2016, 4:51:14 PM2/28/16
to
You're remembering wrong, or incompletely. In order to use ++ with a
user-defined type, one needs to define one's own operator. What do you
think a ++ would do if you gave your enumeration constants specific
values, like

enum Directions { NORTH = 10, EAST = 100, SOUTH = 1000, WEST = 10000 };

? What would it do for 'WEST'? Circle back or become an unnamed value
(integral 4)? There is no default behavior for user-defined types.

As your compiler suggests, define your own operator:

Direction& operator++(Direction& d) {
switch (d) {
case NORTH: d = EAST; break;
case EAST: d = SOUTH; break;
case SOUTH: d = WEST; break;
case WEST: d = NORTH;
}
return d;
}

V
--
I do not respond to top-posted replies, please don't ask

JiiPee

unread,
Feb 28, 2016, 5:54:43 PM2/28/16
to
yes I think this is the safest way. adding +1 can lead to errors later
on if somebody changes their integer values.
so: enum + 1 I think think is not so good idea....

Bob Langelaan

unread,
Feb 28, 2016, 5:54:46 PM2/28/16
to
Thanks muchly :)

Bob

JiiPee

unread,
Feb 28, 2016, 5:57:38 PM2/28/16
to
On 28/02/2016 22:06, Stefan Ram wrote:
> Victor Bazarov <v.ba...@comcast.invalid> writes:
>> As your compiler suggests, define your own operator:
>> Direction& operator++(Direction& d) {
>> switch (d) {
>> case NORTH: d = EAST; break;
>> case EAST: d = SOUTH; break;
>> case SOUTH: d = WEST; break;
>> case WEST: d = NORTH;
>> }
>> return d;
>> }
> Yes. But, /if/ the numerical values are appropriate,
> then one might also:
>
> #include <iostream>
> #include <ostream>
>
> enum direction { NORTH, EAST, SOUTH, WEST, TOP };
>
> direction operator+( const direction d, int const n )
> { return static_cast< direction >
> ( ( static_cast< int >( d )+ n )% static_cast< int >( TOP ) ); }
>
> int main()
> { direction x( NORTH );
> for( int i = 0; i < 9; ++i )::std::cout <<( x = x + 1 )<< '\n'; }
>
> 1
> 2
> 3
> 0
> 1
> 2
> 3
> 0
> 1
>

Not sure how safe this approach is and is it recommended? I mean, what
if somebody changes EAST to say, 5 later on?
In any case, I think with this approach there should be heavy comments
near direction to warn about this, that not to change the integer values.

David Brown

unread,
Feb 29, 2016, 3:12:53 AM2/29/16
to
It is not safe if the enumerated states are anything other than
contiguous from 0, or if they don't have an appropriate order in their
definition. It also involves a good deal more casts if you are using
strongly typed enums.

I don't like the idea of putting an extra marker like TOP into the
enums. TOP is /not/ a direction - yet you (Stefan) have told the
compiler that it /is/ a direction, because it is a member of the type.
Don't lie to your compiler, or to your readers. It also means that you
lose the help your compiler could give you in spotting errors, such as
using the "-Wswitch-enum" warning in gcc.

Making the ++ operator explicit with a switch statement solves all these
problems, though it is more verbose.


> In any case, I think with this approach there should be heavy comments
> near direction to warn about this, that not to change the integer values.

Agreed.

0 new messages