member functions not working properly

This is a discussion on member functions not working properly within the C++ Programming forums, part of the General Programming Boards category; Needing help with my text rpg again. I have two classes that I am using to check and assign which ...

  1. #1
    Registered User
    Join Date
    Apr 2008
    Posts
    17

    member functions not working properly

    Needing help with my text rpg again. I have two classes that I am using to check and assign which decision a user picks. They have 2 choices (warrior or mage). If they choose mage some text is printed, if they choose warrior some different text is printed. My problem is that it only outputs text if they choose mage. Nothing is printed when they choose warrior.

    The first class which assigns the information
    Code:
    class Player {
    public:
         string getPlayerState(int);
         
    private:
         string PlayerState;
    };
    
    string Player::getPlayerState(int x){
        if (x==1) {
            PlayerState = "Warrior";
        }
        if (x==2){
            PlayerState = "Mage";
        }
        if (x != 1 && x != 2){
            cout <<"Error, no PlayerState"<<endl;
        }
        return PlayerState;
    }
    And the class that asks the question.
    Code:
    class Game {
    public:
         void StartGame();
    private:
               int x; //not important
    };
    
    void Game::StartGame() {
               string urname;
               int typeClass; // 1 if they pick warrior, 2 if they pick mage
    
               cout <<"What is your name?"<<endl;
               cin >>urname;
    
               cout <<"[1] Warrior"<<endl;
               cout <<"[2] Mage" <<endl;
               cout <<"Please make a choice"<<endl;
               cin >>typeClass;
    
         Player PlayerInfo; // yes I declared them as friends
         PlayerInfo.setPName(urname); // pass's urname to setPName()
         PlayerInfo.getPlayerState(typeClass);
    
         PlayerInfo.callPlayerUI();
    }
    And the last bit.
    Code:
    Player::callPlayerUI(){
         if (PlayerState == "Mage") {
         cout <<"Something important" <<endl;
         }
         if (PlayerState == "Warrior") {
         cout <<"Totally different text" <<endl;
         }
    }
    Once again, no text is being printed if they pick warrior. I know what the problem is, I just don't know how to fix it. PlayerState never equals "Warrior" and/or int x in getPlayerState never equals 2....even when I explicitly type in 2.

    I think thats all thats needed to help me with this problem...let me know if I am missing something.

  2. #2
    Registered User
    Join Date
    Apr 2008
    Posts
    17
    doh...misplaced }

    only took me 4 hours to figure it out

  3. #3
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,305
    With a cursory glance, it looks okay to me, though it could be improved. I wrote a quick test by converting Game::StartGame() into main() and then fixing the parts that were left out in the example, and it worked. As such, I suggest that you post the smallest and simplest compilable program that demonstrates the problem.

    Incidentally, it might be better to have Warrior and Mage subclasses of a Character abstract base class, then have each Player object keep a (smart) pointer to a Character.

    doh...misplaced }

    only took me 4 hours to figure it out
    Ah well, that's why you should have posted a program that actually demonstrates the problem. I would not have wasted time writing one that shows that the problem does not exist. Still, I suggest that you consider using polymorphism instead of type checking.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,030
    You are assuming that classes are supposed to print text. They aren't.
    Maybe if you make a "Game" class, that's ok, but the rest should absolutely not print text. If something is wrong, they should throw an exception or return an error or just assert.
    Also remember that it's less expensive and easier to keep track of things if they're integer-based and not string-based.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    >> Maybe if you make a "Game" class, that's ok, but the rest should absolutely not print text.

    Logging errors suddenly a bad idea. Wow.

    The OOP idea of messaging is also a bit more sophisticated than just blowing up during runtime "when things are wrong."

  6. #6
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,030
    Quote Originally Posted by citizen View Post
    Logging errors suddenly a bad idea. Wow."
    That's an entirely different thing. Plus it might be better with an assert so you know where it goes wrong in this case.

    And...
    Code:
         if (PlayerState == "Mage") {
         cout <<"Something important" <<endl;
         }
         if (PlayerState == "Warrior") {
         cout <<"Totally different text" <<endl;
         }
    This is hardly logging.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    You got the point.

  8. #8
    Registered User
    Join Date
    Apr 2008
    Posts
    17
    Quote Originally Posted by Elysia View Post
    You are assuming that classes are supposed to print text. They aren't.
    Maybe if you make a "Game" class, that's ok, but the rest should absolutely not print text.
    Woah, woah...let me see if I understand what you said.

    Class's should not print text UNLESS I'm using a "game" class? Why shouldn't class's print text? I am just asking cause I have a game class and it is going to contain all of my text. I would hate to get all of this done just to find out I did it all wrong.

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,030
    The thing is that a class is an object. Just like your car. Your operate it and it responds to you, but it never talks.
    You must make sure to show that to the user.
    There are special classes, you could say however. Like MFC, which wraps an entire app into a class. Obviously, there I would do all the work and print text, etc, because the class was designed to be the main app.

    In short, a class is an object--it's defined to be something. A player class is supposed to represent a player, for example, not something that prints text. If you make a "game" class, it should represent the game itself, and so could print text.

    Is that a bit clearer?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Registered User
    Join Date
    Apr 2008
    Posts
    17
    Quote Originally Posted by laserlight View Post
    With a cursory glance, it looks okay to me, though it could be improved.....

    Incidentally, it might be better to have Warrior and Mage subclasses of a Character abstract base class, then have each Player object keep a (smart) pointer to a Character.

    Ah well, that's why you should have posted a program that actually demonstrates the problem. I would not have wasted time writing one that shows that the problem does not exist. Still, I suggest that you consider using polymorphism instead of type checking.
    Sorry you went through all that trouble over a misplaced bracket. I feel bad now .

    I am coming back from like a 2 year programming break and I am making this little program to springboard myself back into the programming mindset so I just want to get this thing done before I start cleaning it up. I also plan to polish the code once it's complete to learn things I previously didn't know like polymorphism, inheritance and using the heap to keep track of inventoried items. All criticism is more than appreciated but its not quite time for me to ask for that.

    @Elysia
    So it's more of a "good practice" than a requirement..got ya.
    Last edited by bulletbutter; 04-19-2008 at 01:27 AM. Reason: added reply to previous post

  11. #11
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    "Good practice" is a bit too big of an umbrella term for what Elysia's talking about. It's more of a design problem. Bit of a crash course on objects and messaging:

    Like Elysia said, an object usually represents a thing. So nouns make good objects. You could think of a black box that has stuff inside as an object: while the things inside may define what the box does and what it represents. The stuff inside is also kept as secret as possible (usually) but that's a bit of a different topic.

    In a good OOP design, you have to decide whether or not its' appropriate for the object to communicate with the user. Objects that are black boxes communicate to the world (including other objects) through member functions, or whatever might be appropriate for the object to represent its' state. Messaging is a term that defines the way a black box does that.

    For example, you could have chosen to let the Player class represent the user's character, and let the Game superobject run the show. Player would be a simple object that can inform the world if the its' alive, or what events it has been doing (such as CastASpell()) and the Game would manage the events of play. Meaning that the Player would inform the Game of its' state exclusively through "messaging" and the Game class would do something, rather than have the Player class interact with the user.

    But contrary to what Elysia told you, there may be an appropriate OOP design where Player objects work with the user. It's just that you chose to encapsulate the game as an object, in turn bothering OOP evangelists because they would have made several other design decisions like the ones I detailed for you.

    I will state emphatically though that classes can print text and it is appropriate to do so, contrary to Elysia's statement.
    Last edited by whiteflags; 04-19-2008 at 01:51 AM.

  12. #12
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by Elysia View Post
    The thing is that a class is an object. Just like your car. Your operate it and it responds to you, but it never talks.
    You must make sure to show that to the user.
    There are special classes, you could say however. Like MFC, which wraps an entire app into a class. Obviously, there I would do all the work and print text, etc, because the class was designed to be the main app.

    In short, a class is an object--it's defined to be something. A player class is supposed to represent a player, for example, not something that prints text. If you make a "game" class, it should represent the game itself, and so could print text.

    Is that a bit clearer?
    No, in fact it doesn't make sense at all. First of all, a "class" is most definitely not an "object". An object is an instance of a class.

    Second, I don't know why you're hung up on a class having output functionality. In fact, I'd recommend that he implement a friend operator<< for just such a purpose.

  13. #13
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,030
    Quote Originally Posted by medievalelks View Post
    No, in fact it doesn't make sense at all. First of all, a "class" is most definitely not an "object". An object is an instance of a class.
    If you want to be nitpicky, then fine. The instance is an object. But the classes are blueprints for creating those instances, thus the classes themselves can be considered "objects." Whichever fancies your imagination.

    Second, I don't know why you're hung up on a class having output functionality. In fact, I'd recommend that he implement a friend operator<< for just such a purpose.
    This is an entirely different thing. The class shouldn't output anything. But it can overload the operator and return stuff so the controller of the object can output it. In fact, this might be a good idea because the object itself knows best how it's built and how its data should be interpreted.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by Elysia View Post
    This is an entirely different thing. The class shouldn't output anything. But it can overload the operator and return stuff so the controller of the object can output it. In fact, this might be a good idea because the object itself knows best how it's built and how its data should be interpreted.
    That's a design issue that depends on the domain.

  15. #15
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by citizen View Post
    In a good OOP design, you have to decide whether or not its' appropriate for the object to communicate with the user. Objects that are black boxes communicate to the world (including other objects) through member functions, or whatever might be appropriate for the object to represent its' state.
    In good OO design, classes encapsulate behavior. Just providing getters and setters of state is not a lot different than passing structs around.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 04-19-2008, 01:06 AM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 03:39 PM
  3. Static functions.... why?
    By patricio2626 in forum C++ Programming
    Replies: 4
    Last Post: 04-02-2007, 09:06 PM
  4. member functions can't see private data members
    By ichijoji in forum C++ Programming
    Replies: 2
    Last Post: 11-22-2006, 02:36 PM
  5. Templated member functions
    By Highland Laddie in forum C++ Programming
    Replies: 5
    Last Post: 05-15-2006, 06:25 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21