#### Archived

This topic is now archived and is closed to further replies.

# Enumeration?

## Recommended Posts

Well, a few days ago I finally decided to try to learn C++. So I went out to my local Walden Books to find books about it. I bought this book called SAMS Teach Yourself C++ in 21 Days, simply because it looked like it would be the most beneficial. So anyway, I''m a complete newb to C++ (I''m on day 3!) and I understand it so far (I would hope the first few days would be simple!), and then the author throws this "enumeration" thing at me.... And I re-read the section over and over again, but I still don''t understand it... Could somebody help me out, with a better explantion, or an example? Even if you can''t, thanks anyway.

##### Share on other sites
An enumeration is a way to enumerate (look it up) choices.

As the name implies, it NUMERATES (gives numbers to) the choices.

Let''s say you wanted to store your favorite kind of fruit. You could store it in a string, but that takes up more space, and takes longer to test for equality. Instead, you could do this:

  enum fruit_type { apple, pear, orange, plum, grape };fruit_type myFavoriteFruit;myFavoriteFruit = pear;if(myFavoriteFruit == grape){    cout << "Ewww, grapes.\n";}

What''s going on there is that the compiler transparently assigns an integer to each: 0 for apple, 1 for pear, 2 for orange, etc. Then you can use those constants for both assignment and equality.

##### Share on other sites
So, if the system puts out the constant equal to "myFavoriteFruit", one output would be written to the screen, but if another constant from the enumerator was reported, it would write something different to the screen? Thanks.

##### Share on other sites

I always add a numoftypes to the end of an enumeration
ie.

enum fruit_type{apple, pear, orange, plum, grape,num_fruit_types};

Now num_fruit_types will always be equal to the number of "actual" items in your enumeration (as long as you keep it LAST in the list).

TearsKnight,
I have a lot of books on C++, and one book in particular helped understand how to use enumerations in practical apps and games. I will send you the source code of a card game example. In case you were wondering... it uses enumerations for the suits and for the face cards.
ie.
enum suit_type{ hearts, diamonds, clubs, spades};

you can also start enumerations at higher numbers if you don't want it to start at 0 for some reason. like the face cards you would want the jack to start out at 11, the queen 12 and so on.
(I might get the syntax wrong here, I'll check later)

enum card_type{ 11,jack,12,queen,13,king,14,ace};

[edited by - zenassem on July 16, 2002 2:10:03 PM]

##### Share on other sites
i dont like to read books on programming.I learned Visual Basic(soon ill learn C++)by buying a CD from cdlearning.com
its really great you barely have to read anything ,just put on you headfones and 2 different people(male and female)walk you through everything with Examples on everything they talk about.
the only setback is its \$50 but ive bought the cd for HTML and Visual and i plan to buy C and C++ when school starts.

##### Share on other sites
Using the above enum is similar to doing something like this...

int apple = 0;
int pear = 1;
int orange = 2;
int plum = 3;
int grape = 4;

...but much much nicer and less error-prone.

Sneftel''s good example prints out "Ewww, grapes." if the variable myFavouriteFruit is equal to grape. If it''s not equal to grape, nothing is printed (i.e. not something else).

How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

##### Share on other sites
zenassem - the correct syntax for your last example:

enum card_type{ jack = 11, queen = 12, king = 13, ace = 14};

Unless something in the langauge changed on me within the last year. o.O

--------------------------
"Facing terror isn''t half as fun as sharing it" -- Bun-bun

##### Share on other sites
Thanks creation! Yes that''s the CORRECT syntax that I was trying to pull out of my brain.

##### Share on other sites
Well, I think I understand it now. So it''s just a convenience type thing? Thanks.

##### Share on other sites
quote:
Original post by siaspete
...but much much nicer and less error-prone.

nahh...
It just increases the chance of bugs, and decreases readabillity...

  void func(bool useGrapes, bool dontUseOranges) {  ...}

now here you can not realy understand the meaning, of a function call, unless you look at the name of the paramenters, or use defs, like:

#define USEGRAPES true
#define DONTUSEGRAPES false

but then, a programmer unfamiliar with the function might, by mistake, put USEGRAPES (or true) in the dontUseOranges paramenter and it then has the opposite meaning...

now...

  enum UseOfGrapes {  GrapesUse,  NoGrapesUse};enum NoUseOfApples {  NoAppleUse,  AppleUse};void func(UseOfGrapes useGrapes, NoUseOfApples useApples) {  ...}

now here, if you put GrapesUse in the useApples paramenter, the compiler will spit out an error on compiletime, intead of a bug at runtime!

So, enums is your friend, so use them whenever it''s possible!

##### Share on other sites
quote:
Original post by Coward
nahh...
It just increases the chance of bugs, and decreases readabillity...

That's what he was saying, IMO; that the use of enums is more readable than his #define counterexample.

quote:

enum UseOfGrapes {
GrapesUse,
NoGrapesUse
};
enum NoUseOfApples {
NoAppleUse,
AppleUse
};

Yuck. Yuck yuck yuck. There is a time for enums, and a time for variables that are not enums.

If you use enums to explicate every boolean parameter, you will horribly clutter the namespace. Furthermore, booleans are in the language because their meaning is clear; a programmer whose function takes an argument of the form "dont_do_xxx" is following a very very bad form. True == do == yes == positive == successful == etc.

quote:

...now here you can not realy understand the meaning, of a function call, unless you look at the name of the paramenters, or use defs...

If you're not looking at the function parameters to understand a call, you should be. In the case of functions where the use of each argument is not obvious, comments suffice. As shown:

    fh =foo->open_serial(    "COM1:", // first serial port    true,    // allow buffering    false,   // don't convert newlines    128,     // the buffer size    50);     // the timeout value

Obviously I wouldn't do that for every function; but where the argument lists are long and the functions unfamiliar, it increases readability far better than enums could. After all, how would you force the programmer not to mix up the buffer size and the timeout value?

quote:
So, enums is your friend, so use them whenever it's possible!

Use enums when you have a predefined list of options, which is either three or more options, or two options and a boolean doesn't make much logical sense.

Don't listen to me. I've had too much coffee.

[edited by - sneftel on July 17, 2002 2:14:00 AM]

##### Share on other sites
sure, that example was a bit obfuscated, it was merely an example where enumerations would make it more readable...

If you've got code like that, it would proberly be better to split the function up, or atleast make one "actions" paramanter, but I was merely trying to show enums vs. boolens using code that is pretty equal...

I've got loads of examples where a boolean value that's true means that something shouldn't be done, so I must say I don't agree on your "true is equal to do it" statement...
do you never use else?

[edited by - Coward on July 17, 2002 1:14:10 PM]

##### Share on other sites
Your right; my proscription of "negative" booleans was a little too absolute. I still think, though, that unless there is some other design principle you''re trying to maintain, it''s better to use positive booleans.

Your point about the actions parameter is a good one, and makes me wonder why people don''t use bit-packed structures more often instead of the long lists of #defines, each setting one bit. I wonder... will C++ allow you to stick a 1-bit bool in a bit-packed struct?

• ### Forum Statistics

• Total Topics
628366
• Total Posts
2982274

• 10
• 9
• 13
• 24
• 11