Using enumerations in classes

In another thread it was suggested to use an enum for gender in Human class.

Is this how you would implement the idea:

Code:

#include <iostream>

class Human
{
    public:
        enum gender {male, female}; //public, so they would be accessible in main()
        Human(gender g): m_gender(g) {}
        ~Human() {};
        gender getGender() //or should it return int?
        {
            return m_gender;
        }
    private:
        gender m_gender; actual gender, therefore private
};

int main()
{
    Human man(Human::male); //is this right?
    Human woman(Human::female);
    std::cout << man.getGender() << " " << woman.getGender() <<
    std::endl;
    std::cin.get();
}

Does it work? It looks ok to me.

It shows 0 and 1

Sure, that looks good. ...but depending on how you further implement, if gender is just going to be an enum, then there really would be no difference between Human::male and Dog::male, so why not just make it global? I generally only use class enums for protected and private situations. In this case, it just seems unnessasary to me to have it in class scope, but I could be wrong about this logic.

Well, you have the scoping of the class. Also, a global gender is not necessarily the same: if you apply the gender to words, you'd have to introduce a third value "neuter", which does not make sense for humans.

Yes, it outputs the numeric value of the enum value. You usually solve this by using a lookup table on the values.

Some people are biologically born with parts of both genders and do not want to be called "male" or "female", one way or the other... so you may want to add "neutral" or "N/A" to the enum to be politically correct. And if this is for user input, some people might not want to disclose their genders for some reason.

Originally Posted by CornedBee

Well, you have the scoping of the class. Also, a global gender is not necessarily the same: if you apply the gender to words, you'd have to introduce a third value "neuter", which does not make sense for humans.

Have you ever heard of a vasectomy? That was my point. As long as the enum accounts for all global possibilities then making it public to the class rather than global seems pointless to me. However, if thought about more, the only condition humans really can't fill in gender is Asexual. So global may be impossible here, but again, it really depends on where his program is going.

Originally Posted by jafet

Some people are biologically born with parts of both genders and do not want to be called "male" or "female", one way or the other... so you may want to add "neutral" or "N/A" to the enum to be politically correct.

Bah... I've never played a politically correct RPG in my life then because all (that I know of) computer or console RPGs only offer Male and Female as gender choices. Now, do you think Oblvion would have used a global gender enum or enums local to each of their races even though they all were male and female? However, if you are talking about some form of Database or something that does take input from users about themselves, then I'd say N/A is a good option.

Code:

#include <iostream>

class Human
{
    public:
        enum gender {male, female}; //public, so they would be accessible in mai
n()
        Human(gender g): m_gender(g) {}
        ~Human() {};
        gender getGender() //or should it return int?
        {
            return m_gender;
        }
    private:
        gender m_gender; // actual gender, therefore private
};

std::ostream& operator<<(std::ostream& os, const Human::gender gender)
{
    switch( gender )
    {
        case Human::male:
            os << "Male";
            break;
        case Human::female:
            os << "Female";
            break;
        default:
            os << "Unknown";
            break;
    };

    return(os);
}

int main()
{
    Human man(Human::male); //is this right?
    Human woman(Human::female);
    std::cout << man.getGender() << " " << woman.getGender() <<
    std::endl;
    std::cin.get();
}

Originally Posted by SlyMaelstrom

Now, do you think Oblvion would have used a global gender enum or enums local to each of their races even though they all were male and female?

I very much doubt that big RPG games even have any classes beyond Character, and perhaps a distinction between PCs and NPCs. They tend to be completely driven by data loaded at runtime from data files.

Originally Posted by CornedBee

I very much doubt that big RPG games even have any classes beyond Character, and perhaps a distinction between PCs and NPCs. They tend to be completely driven by data loaded at runtime from data files.

Oh, come on... it was an example, and I said would have, not did. Considering that each race has almost exactly the same functionality in oblivion, I agree with you, however the point was made in that post and you're really just pulling my example out of context there.

OK, let's assume there's a hierarchy there, then. I'd still put the enum into the base-most class where it makes sense.

Look at what I have started...

You actually have started something interesting. Two points of view that are both right. It's a matter of preference mostly (although some design choices may make one a bad choice while others may make it a better a choice).

It's in defending or seeing others defeding their points of view that we learn most.

Personally I'm more inclined towards Sly's. An enum definition simply defines a type. The "OMG-Don't-make-globals!" doesn't apply here. If we have several base classes that have somewhere inside a gender enum we are complicating things if later on we need to add a new gender ("neuter", "asexual", etc...). Having one central global enum definition makes things easier to maintain.

I'm not about avoiding globals, I'm about associating concepts with concepts they depend upon.

In the case of gender, you are right, it's for a large part preference, but I still have a good reason to prefer my way.

Originally Posted by CornedBee

I'm not about avoiding globals, I'm about associating concepts with concepts they depend upon.

In the case of gender, you are right, it's for a large part preference, but I still have a good reason to prefer my way.

in this case a happy middle ground might be to define gender inside a namespace where all the different character classes reside (especially if you don't want a big inheritence hierarchy).