Incrementing enum types

check out this program

#include <iostream.h>
#include <iomanip.h>

typedef char* STRING;
typedef char NAME [41];
typedef double AMOUNT;
enum DAY {mon, tue, wed, thu, fri, sat, sun};

int main()
{
STRING day_names [7] = {"Monday", "Tuesday", "Wednesday"
, "Thursday", "Friday", "Saturday", "Sunday"};
AMOUNT sales [7];
NAME salesperson;
AMOUNT max_sales,
total_sales;
DAY day,
max_day;

cout << setprecision (2)
<< setiosflags (ios::fixed)
<< setiosflags (ios::showpoint);

cout << "\nEnter the name of the salesperson: ";
cin.getline (salesperson, 41);

for (day = mon; day <= sun; ++int(day))
{
cout << "\n\nEnter the sales for " << day_names[day] << ": ";
cin >> sales [day];
}

total_sales = 0;
max_day = mon;
max_sales = sales[mon];

for (day = mon; day <= sun; ++int(day))
{
if (sales[day] > max_sales)
{
max_sales = sales[day];
max_day = day;
}
total_sales += sales[day];
}

cout << "\n\nThe total sales for " << salesperson
<< " is " << total_sales << ".";
cout << "\n\nThe highest sales was " << max_sales << ".";

cout << "\n\nThe highest sales occurred on "
<< day_names[max_day] << ".";

return 0;
}


I get two errors telling me that I can't increment the day variable even tho i declared it as an int in the for loop. Is this compiler specific? I'm using microsoft visual C++

You could try this:

++day;

but since enum are user defined types, the ++ operator may not be defined for enums, eventhough an enum is an int by another name. Won't hurt to try if you haven't already

If that doesn't work you could try casting to an int and then incrementing:

((int)day)++;

but that might not work since you are probably incrementing the int and not the enum it was casted from. Again easy enough to try.

If those don't work, then I would probably use an int as though it were an enum. As indicated above enums are ints by aother name. You can use ints to represent enums, as long as the int is a valid enum value. enum values start at zero by default and increment by one for each additional enum. Obviously you can override the default settings if you want to. Therefore I would try something like this:

int i;
for (i = 0; i < 7; ++i)
{
cout << "\n\nEnter the sales for " << day_names[i] << ": ";
cin >> sales [i];

Yeah, the books I have say that you can't use arithmetic with enums, although I wouldn't doubt if some compilers out there let you do it. You'll have to cast it. I'm not sure if what elad wrote would work:

((int)day)++;

But this should work on any compiler:

day=int(day)+1;

still get:

error C2440: '=' : cannot convert from 'int' to 'enum DAY'
Conversion to enumeration type requires an explicit cast (static_cast, C-style cast or function-style cast)

:mad:

day=DAY(int(day)+1);

/applause

x gets the prize!

now why the hell did that work?

:confused:

because you are casting it as an int to increment it, then you have to cast that int as a DAY to get the desired result.

i.e. enum types have int equivalents

so say you have day as mon. mon = 0. so you cast it as the int equivalent, which is zero, add 1, then cast that int (which is 1) as a DAY; hence you end up with tues.

edit: this should be done because day is of type DAY

wow, that even makes sense!

Hey I'm really happy to have found this board, I'm an IS major who's taking C++ atm. I really love the language, I guess because last semester I took COBOL.

Anyway, thanks for all the replies and help! :D

wow, that even makes sense!

Hey I'm really happy to have found this board, I'm an IS major who's taking C++ atm. I really love the language, I guess because last semester I took COBOL.

Anyway, thanks for all the replies and help! :D

You can do arithmetic just as you wanted with C enum types, but this is not supported in the C++ standard.

However, it turns out that your program works fine in Dev-C++ ver.4 and Borland C++ Builder 5.5. I guess those two compilers are "non-standard" in this respect. In unixland, the CC and g++ compilers both gave errors like the one you got from MSVC.

So you have to go through contortions like xsquared's solution to use the enum the way you wanted.

But why use enum at all in your program? You're not using it to restrict user input, because in your app the user is never asked to input the day. So why not just:

Code:

---

...
int day;
...
for (day = 0; day <=6; ++day)
...

---

Granted, your original way did add a little to the program's readability, but I think the meaning of a variable named "day" with values from 0-6 is pretty obvious anyway. And if you have to do this

Code:

---

day=DAY(int(day)+1);

---

to count through the days, I think that negates any readability benefit, and that the simpler approach, just using ints, is more readable.

oh im just going through lessons and examples in my textbook. Right now im trying to learn structures and enums. So yeah it was prolly redundant to use enum in that, but it's helping me learn enums.

Use code tags!

You can always just overload operators for your enumerated types.

What I usually do to make working with multiple different enum types quick and easy, as well as to avoid name conflicts, is I don't ever use the c++ enum type anymore, but instead use standardized integral types of defined length and format. This, firstly, makes your code much more easily to be portable. Next, I made a templated Enumeration class with 1 template parameter for the [usually] integral type to be used. The class completely consists of inline protected members and overloaded operators, and is simply used as a base from which to derive your "enums."

Then, anytime you want a new type of enumeration, you create a new class for it, use private inheritance on the Enumeration type with the integral template parameter to optimize how much space you need for the type (IE an 8-bit unsigned int if the enumeration only needs a small range of possible values, or even an unsigned 64 bit integer if you are using a very large set of bitflags). Inside the class definition you define public static constants of the template type, which you use to act as your enum constants. Finally, you promote any member functions from the base to be public in the child, picking and choosing which functions to promote depending on whether or not it makes sense to, for instance, incremement an instance.

You still get typesafety, although now on an object level. Also, since the enumerations are all privately derived from the Enum type, you can't convert to the base, which is good, because they should be thought of as completely different types.

So now, whenever you need an enumeration of a certain type, you use the object type. You specify it's value by doing ObjectType::ConstantName. You only use the constant names as temporary objects for construction. You should never explicitly declare an object of the interal type.

The only downside is that it's, of course, possible to construct the object with a different constant if the integral type is the same or if there is a built-in conversion between the types. This only happens during construction because everywhere else, you use the object's type, not the integral type. Also, if you consider other solutions, such as opengl's "super enum," they lack any form of typesafety on enumerations because they use exactly the same type for all of them (of course, since opengl is procedural there wasn't much of a choice)!

Since the constants are public, static and nested in the class definitions, you never have to worry about name conflicts, but you can still access them externally. If you have ever worked with a lot of enumerations, you know what I'm talking about. For instance, it makes sence to have a None constant for many different enumerations which would normally result in conflicts. Since, with my implementation, the constants are encapsulated in their appropriate type definitions, name conflicts are never a problem, so you can have many types with enumerations of the same name, without ever having problems.

Since the integral type is a template parameter, not only do you benefit from control of the size, etc. but it also makes it very simple to work with fileio. When using enum, you have no control of the size of the datatype (unless you use bitfields, though even then, you may have format problems and you have no way of creating a constant of larger size than your compiler's enum). With my implementation, you get low-level control with high-level benefits, and because all of the member functions are inlined, speed should not be an issue.

the correctest solution in c++ as has already been noted and as i would have told you about 8 hrs ago if not for that poxy error that plagues this board is to overload the ++ operator. You should view xsquared solution as a legal hack. In fact you would use a very similar hack inside of operator ++ but you would also get the benefit of not falling off the end of your enum.

what about just making it an int.

int DAY = MONDAY;
DAY++;

that should work for ye

Quote:

---

Originally posted by Silvercord
what about just making it an int.

int DAY = MONDAY;
DAY++;

that should work for ye

---

Because then you would completely lose type-safety between different enumerated types.

so? enums are usually used as labels to help the programmer know what's going on. I usually only see them as labels for indices into arrays. enums are seen as ints anyway, you can have a function that takes an int and pass in an enumerated data type. Type safety is awesome!

EDIT:
You are really going to hate me poly, but here are the two options

1) use an int
2)

Quote:

---

What I usually do to make working with multiple different enum types quick and easy, as well as to avoid name conflicts, is I don't ever use the c++ enum type anymore, but instead use standardized integral types of defined length and format. This, firstly, makes your code much more easily to be portable. Next, I made a templated Enumeration class with 1 template parameter for the [usually] integral type to be used. The class completely consists of inline protected members and overloaded operators, and is simply used as a base from which to derive your "enums."

Then, anytime you want a new type of enumeration, you create a new class for it, use private inheritance on the Enumeration type with the integral template parameter to optimize how much space you need for the type (IE an 8-bit unsigned int if the enumeration only needs a small range of possible values, or even an unsigned 64 bit integer if you are using a very large set of bitflags). Inside the class definition you define public static constants of the template type, which you use to act as your enum constants. Finally, you promote any member functions from the base to be public in the child, picking and choosing which functions to promote depending on whether or not it makes sense to, for instance, incremement an instance.

You still get typesafety, although now on an object level. Also, since the enumerations are all privately derived from the Enum type, you can't convert to the base, which is good, because they should be thought of as completely different types.

So now, whenever you need an enumeration of a certain type, you use the object type. You specify it's value by doing ObjectType::ConstantName. You only use the constant names as temporary objects for construction. You should never explicitly declare an object of the interal type.

The only downside is that it's, of course, possible to construct the object with a different constant if the integral type is the same or if there is a built-in conversion between the types. This only happens during construction because everywhere else, you use the object's type, not the integral type. Also, if you consider other solutions, such as opengl's "super enum," they lack any form of typesafety on enumerations because they use exactly the same type for all of them (of course, since opengl is procedural there wasn't much of a choice)!

Since the constants are public, static and nested in the class definitions, you never have to worry about name conflicts, but you can still access them externally. If you have ever worked with a lot of enumerations, you know what I'm talking about. For instance, it makes sence to have a None constant for many different enumerations which would normally result in conflicts. Since, with my implementation, the constants are encapsulated in their appropriate type definitions, name conflicts are never a problem, so you can have many types with enumerations of the same name, without ever having problems.

Since the integral type is a template parameter, not only do you benefit from control of the size, etc. but it also makes it very simple to work with fileio. When using enum, you have no control of the size of the datatype (unless you use bitfields, though even then, you may have format problems and you have no way of creating a constant of larger size than your compiler's enum). With my implementation, you get low-level control with high-level benefits, and because all of the member functions are inlined, speed should not be an issue.

---

I know using an int isn't 'correct' because you want your day to be its own data type. It just seems easier to use an int, it is what I would do. I pay a lot for ibuprofen as it is :(

Quote:

---

Originally posted by Silvercord
so? enums are usually used as labels to help the programmer know what's going on. I usually only see them as labels for indices into arrays.

---

They are also often used for bitflags, etc. If you wish to only look at the types as "labels," that's fine, but in C++, they are each completely new types, each with their own separate functionality, and they cannot be implicitly cast between by default.

Quote:

---

Originally posted by Silvercord
enums are seen as ints anyway

---

No... They are completely different types, there is just implicit conversion to ints (the typesafety comes from not being able to implicitly cast between other enum types. The reason enums can be implicitly converted to ints is most-likely just for compatability with C, which was much less typesafe than C++). It's the same reason that you can pass a char to a function that takes an int. That does not make a char "seen as" an int, does it :p

Quote:

---

Originally posted by Silvercord
You are really going to hate me poly, but here are the two options

1) use an int
2) /* COOL STUFF GOES HERE */

---

I'll take the latter :p

but it works as being seen as an int
from the frustum culling tutorial from gts for example

Code:

---

enum PlaneData
{
        A = 0,                                // The X value of the plane's normal
        B = 1,                                // The Y value of the plane's normal
        C = 2,                                // The Z value of the plane's normal
        D = 3                                // The distance the plane is from the origin
};

void NormalizePlane(float frustum[6][4], int side)
{
//BLAH
}
...
        NormalizePlane(m_Frustum, RIGHT);

---

that's all I was getting at.

EDIT: now you're probably ........ed off at me too.

Quote:

---

Originally posted by Silvercord
but it works as being seen as an int
from the frustum culling tutorial from gts for example
that's all I was getting at.

---

I know what you're getting at, but my point is that you can also call the function by doing

NormalizePlane(m_Frustum, '\t') // char "being seen as an int"

My point is that even though they can in some cases be implicitly converted between, they are still separate types with separate rules and different functionality.

an enum isn't much more like an int than a char is, but the benefit of enums is that you have typesaftey between enums, they can have different operations, etc. Also note that the implicit conversion for enums is only one-way to ints.

Quote:

---

Originally posted by Silvercord
EDIT: now you're probably ........ed off at me too.

---

OMG DUDE, I HOPE YOU DIE!

P.S. Kidding

EDIT: HAHAHAHAHAHA Just kidding, I totally meant that.

Quote:

---

OMG DUDE, I HOPE YOU DIE!

P.S. Kidding

EDIT: HAHAHAHAHAHA Just kidding, I totally meant that.

---

oy vei :rolleyes:

How do you overload the ++ operator for an enumerated data type? I've never seen that done before.

Hey Poly guess what? I'm starting to do BSP. I'm not writing a partitioner like you did (which seems really really cool), but I'm working on getting it loaded, and then setting up the binary tree to determine what sector you are in and then doing collision/frustum tests against those polygons, etc. I just started on it today, but I've got a clear idea of how it works and how the file is laid out.

Quote:

---

Originally posted by Silvercord
oy vei :rolleyes:

How do you overload the ++ operator for an enumerated data type? I've never seen that done before.

---

depends if you're refering to prefix ++ or postfix ++

Code:

---

// Prefix ++
inline SomeType& operator ++( SomeType& Source )
{
  return Source = SomeType( Source + 1 );
}

// Postfix ++
inline const SomeType operator ++( SomeType& Source, int )
{
  SomeType Temp = Source; return ++Source, Temp;
}

---

Quote:

---

Originally posted by Silvercord
Hey Poly guess what? I'm starting to do BSP. I'm not writing a partitioner like you did (which seems really really cool), but I'm working on getting it loaded, and then setting up the binary tree to determine what sector you are in and then doing collision/frustum tests against those polygons, etc. I just started on it today, but I've got a clear idea of how it works and how the file is laid out.

---

Supar :D