OK, I have a class "cRoom" that has a multidemensional array "theRoomMap[5][10]" as a private member. Now in the class "cRoom" I have a method "upDateMap()" that updates theRoomMap. So far so good, but I have another class "cPlayer" that has a method "putPlayerInMap(int yUnits, xUnits)", which calls the cRoom::upDateMap function. But the compiler doesn''t allow this for it says that I can''t call a non-static member. But if this is the case, why can I call std::cout, for example? I tried using "friend cPlayer" but that makes it worse. And I don''t want to derive the cPlayer from cRoom "class cPlayer: public cRoom". So is it not possible for one class to use another class’s methods (functions)? I''m using MSVC++.NET 2002. Thanks. "Do not flame people you don''t know in a public forum. Only amateurs do that. Professionals in the industry know they will run into each other over and over. The person you flame this year may the person you want to do business with next year. Don''t burn your bridges," (Diana Gruber, http://www.makegames.com/chapt6.html).

quote:Original post by DIRECTXMEN
OK, I have a class "cRoom" that has a multidemensional array "theRoomMap[5][10]" as a private member. Now in the class "cRoom" I have a method "upDateMap()" that updates theRoomMap. So far so good, but I have another class "cPlayer" that has a method "putPlayerInMap(int yUnits, xUnits)", which calls the cRoom::upDateMap function. But the compiler doesn''t allow this for it says that I can''t call a non-static member.

You need a cRoom object in order to call a non-static member function (on the object). It needs to be a static member function if you''re going to call it with no object but just using the class name (as "cRoom::upDateMap()"). I assume that theRoomMap is a static array of cRoom? In this case, yeah, you''re looking at a static member function, though you should be careful with this kind of design - make a note to check later on if there isn''t a better place to put theRoomMap.

quote:But if this is the case, why can I call std::cout, for example? I tried using "friend cPlayer" but that makes it worse. And I don''t want to derive the cPlayer from cRoom "class cPlayer: public cRoom". So is it not possible for one class to use another class?s methods (functions)?

You''re clearly quite confused; std::cout isn''t a function but an object, so you can''t "call" it - what you''re calling there is operator<<.

You can use anything from another class which is accessible according to the data-hiding rules (public/protected/private). OO would be pretty useless if classes couldn''t communicate with each other.

But yeah, this is a question of the object vs. the class. Basically, static methods are _stdcall (using the class as a sort of packaging mechanism, except that you get access to private data of that class - including private members of objects of that class, if you can find such objects within the function) and non-static methods are _thiscall (requiring an object for invocation, so that "this" is defined).

quote:Original post by DIRECTXMEN
So far so good, but I have another class "cPlayer" that has a method "putPlayerInMap(int yUnits, xUnits)", which calls the cRoom::upDateMap function. But the compiler doesn't allow this for it says that I can't call a non-static member.

What you're trying to do makes no sense, really. You seem to be trying to put a player into a room class rather than a room object , which is of course not allowed unless the method is static. That's sort of like saying that you want the player to be inside the abstract concept of 'room', rather than in any specific room.

If you want to put a player inside a specific room's map, you should just pass a pointer or reference to a cRoom object to cPlayer:: PutPlayerInMap.

[edited by - twix on March 19, 2004 12:52:34 PM]

quote:Original post by twix
What you''re trying to do makes no sense, really. You seem to be trying to put a player into a room class rather than a room object , which is of course not allowed unless the method is static. That''s sort of like saying that you want the player to be inside the abstract concept of ''room'', rather than in any specific room.

If you want to put a player inside a specific room''s map, you should just pass a pointer or reference to a cRoom object to cPlayer:: PutPlayerInMap.

It does make sense, really. The member theRoomMap[5][10] is not abstract but specific for the coder (that''s me) has to make a method call when initializing.

myRoom->setRoom(myRoom);

This takes myRoom and copies verbatim into theRoomMap, but whatever. Anyway, I took the cPlayer class and made it a member of the cRoom class. Now all is right with the world.




"Do not flame people you don''t know in a public forum. Only amateurs do that. Professionals in the industry know they will run into each other over and over. The person you flame this year may the person you want to do business with next year. Don''t burn your bridges," (Diana Gruber, http://www.makegames.com/chapt6.html).

Say you have this cRoom class.
You make 3 rooms, called a, b, c, each with their own theRoomMap. Now a player x wants to call upDateMap(). In which room ?
Obviously you would call a.upDateMap() instead of cRoom::upDateMap().

quote:Original post by Fidelio66
Say you have this cRoom class.
You make 3 rooms, called a, b, c, each with their own theRoomMap. Now a player x wants to call upDateMap(). In which room ?
Obviously you would call a.upDateMap() instead of cRoom::upDateMap().

Well unless the player interacts with the game by typing in code I don't think the player has to worry about what methods are called. And the player is only in one room at a time, so there is no ambiguity. And why "a"? Maybe he's in b...

Basically what I wanted to do was have one class’s method call another's method.

include "cRoom.h"include "cPlayer.h"cPlayer::putPlayerInMap(int* y, int* x, char* playerSymbol){     cRoom::updateMap(y, x, playerSymbol);}

But as always, there are a billion ways to do the same thing. So, I choose number 9,456,567 way of doing it.



"Do not flame people you don't know in a public forum. Only amateurs do that. Professionals in the industry know they will run into each other over and over. The person you flame this year may the person you want to do business with next year. Don't burn your bridges," (Diana Gruber, http://www.makegames.com/chapt6.html) .

[edited by - DIRECTXMEN on March 24, 2004 4:59:36 PM]

You''re right, I meant a cPlayer instance called x.

You can, if you make updateMap() and theRoomMap[] static. Then they are in the class definition and not in the objects that you create. This means that there is only one theRoomMap[] of course.

I''m not going to go into the full scope of it, but generally even if you only are ever going to have one instance (object) of a class, you should still just do it the right way! Ie. just create a "currentRoom" that is an object of type "cRoom" or whatever.

Trying to it all with static functions etc. is just C coding... there''s nothing object oriented about it, and you''re effectively just using global variables and all the garbage that comes with them. The three main points of object orientation are encapsulation, polymorphism and inheritance... none of which you can take advantage of doing it the way that you are.

quote:Original post by AndyTX
Trying to it all with static functions etc. is just C coding... there''s nothing object oriented about it, and you''re effectively just using global variables and all the garbage that comes with them. The three main points of object orientation are encapsulation, polymorphism and inheritance... none of which you can take advantage of doing it the way that you are.

Are you sure about that? Classes are the basis of OOP in C++. And who said I''m using global variables or static functions? I''m using a class, which defines a type or object (in this case "cRoom"). I also have private members, which are only accessible via public methods (a.k.a. encapsulation). I may not be using function overloading, operator overloading, virtual functions, or even templates but that''s because I didn''t need to.