Archived

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

Accessing class methods in an another un-derived class...

This topic is 5011 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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).

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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().

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
quote:
Original post by DIRECTXMEN
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.



Yes, classes form the basis of OOP, but simply having classes in your code does not in itself make your code OOP. What AndyTX is saying is that the way that you are actually using your classes is no better than using globals and old fashioned C-style programming. You aren''t really getting the benefit of classes.

Share this post


Link to post
Share on other sites
quote:
Original post by DIRECTXMEN
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.


You are breaking encapsulation by making cPlayer a part of cRoom. You're exposing the functionality of the room to the player class and vice versa. The functionality of the two classes should be completely separate.

Why on earth is a player a part of a room? Will every room have a player associated with it? If you're going to try to make your program object oriented, you need to think in an object oriented way. Right now, you're just hacking together what's most convenient without a thought for the structure of the program. Be careful!

[edited by - twix on March 24, 2004 5:49:45 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by DIRECTXMEN
Basically what I wanted to do was have one class’s method call another's method.

include "cRoom.h"
include "cPlayer.h"

cPlayer:utPlayerInMap(int* y, int* x, char* playerSymbol)
{
cRoom::updateMap(y, x, playerSymbol);
}



So, what does that mean, exactly? Let's say you have a player named Player. You call Player.putPlayerInMap(1, 2, 'P'). So then what happens? You call cRoom::updateMap, which does NOT belong to any specific room, but the global cRoom class. That means that this method is no different from a global function, and the cRoom class is no different from a single, global room structure because you CANNOT make multiple rooms and have this work. There's no object orientation here, folks.
quote:

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


Unfortunately, 999,999,990 of those ways are usually wrong.

[edited by - twix on March 24, 2004 6:02:48 PM]

Share this post


Link to post
Share on other sites
All you had to do was make "upDateMap()" public instead of private. The player could then access it.

Oops! You wanted to know why some stuff can be accessed directly. If you make a member function static it can then be accessed all the time( globally )

eg
...
float dt = Timer::GetTime()
..

where GetTime is a static method of the Timer class.

The thing with std::cout is that std is a namespace so it works differently.

so in your cas you would do

class cRoom
{
...
static void upDateMap();
...
}

then the player could access it lijke this

cRoom::upDateMap();

One thing to keep in mind though is that static methods MUST use static member data. Which means that all your rooms would have to share the same room array.

Hope that helped.

Pete

Share this post


Link to post
Share on other sites