Thread: problem with class

see my second example... the danger is called a memory leak - if you run the program enough times, theoretically your system would run out of memory. in the learning stages it's not a big danger, but imagine in a company that keeps the program running all day long...

basically, just remember that for every new, you need a correspoding delete, and for every new[], you need a delete[]

I'm sorry. that was my first example they were in...

you could, except in the case where you're constantly creating new ones... for example, take this code for a linked list. you'll notice that new and delete actually occur in loops:

Code:

#include<iostream>      //for console I/O
#include<string>        //for string class

struct node;            //prototyped for linking in itself

struct node             //structure
{
        std::string data;       //to hold the data
        node*link;              //a pointer to the next one in the list
};

int main()
{
        std::string line;       //to hold input

        node*head=new node;     //this pointer holds the head of the list
        node*curr=head;         //this is where the work is done
        node*next=head;         //this is to help move down the list
        curr->link=0;           //set the pointer to null to avoid problems

        std::cout<<"Enter some lines of text:\n\n";

        for(;;)         //semi-infinite loop
        {
                getline(std::cin,line,'\n');    //get input

                if(line=="")    //if there's no input
                {
                        curr->data=line;        //put that in the last one
                        break;  //break out of the loop
                }

                curr->data=line;        //else, put the data in the structure
                next=new node;          //create a new structure in memory
                curr->link=next;        //make the pointer point to it
                curr=next;              //move into it
                curr->link=0;           //and make that pointer null
        }

        curr=head;                      //go to the top of the list
        std::cout<<"You Entered:\n\n";

        while(curr->data!="")           //while there's data
        {
                std::cout<<"> "<<curr->data<<std::endl; //output it
                next=curr->link;        //save the location of the next one
                curr->link=0;           //nullify this link
                delete curr;            //delete this one
                curr=next;              //move into the next one
        }
        delete curr;    //delete the last one (with no data in it)

        return 0;
}

If you only have one class for all the data, why not just declare your object outside of everything, so you will not have to pass reference to the class. Why would you need to pass a reference to it, its not like there are going to be 1-5 players, or 1-1000000 in the case of Warcraft. I dont believe this has any negative effects, but if it does, you could pass the reference, which I'll show in the next post a different version of this.

Code:

#include <iostream>

using namespace std;

typedef unsigned short int USHORT; //makes your own variable, USHORT, which is an unsigned short int

class Player_Stats
{
private:
  USHORT itsLevel;

public:
  Player_Stats():itsLevel(0) {} //constructor, initializing itsLevel variable to 0

  USHORT GetLevel() const { return itsLevel; }
  void SetLevel(USHORT level) { itsLevel = level; }

};

Player_Stats pStats;

void aFunction() {
  cout << pStats.GetLevel() << endl; //output: 0
  pStats.SetLevel(10);
  cout << pStats.GetLevel() << endl; //output: 10
}

int main()
{
  aFunction();

}

Like said above, you make your variables in the class private, and make functions to return/set them if necessary in the public, this is if you plan on using them outside that class. You could always do most of your game using all classes, functions of the class, derived from the class, friend of the class, etc. as mentioned above.

generally you should try not to create things globally... if you really wanted to, however, you could also do this:

Code:

class Player_Stats
{
  private:
    USHORT itsLevel;

  public:
    Player_Stats():itsLevel(0) {} //constructor, initializing itsLevel variable to 0

    USHORT GetLevel() const { return itsLevel; }
    void SetLevel(USHORT level) { itsLevel = level; }

} pStats;

also, I just noticed that your class was missing a semi-colon.

Passing a reference OF the object of the stats class:

Code:

#include <iostream>

using namespace std;

typedef unsigned short int USHORT; //makes your own variable, USHORT, which is an unsigned short int

class Player_Stats
{
private:
  USHORT itsLevel;

public:
  Player_Stats():itsLevel(0) {} //constructor, initializing itsLevel variable to 0

  USHORT GetLevel() const { return itsLevel; }
  void SetLevel(USHORT level) { itsLevel = level; }

};

void aFunction(Player_Stats& pStatsCopy) /* argument takes the memory location to an object of Player_Stats class */
{
  cout << pStatsCopy.GetLevel() << endl; //output: 0
  pStatsCopy.SetLevel(10);
  cout << pStatsCopy.GetLevel() << endl; //output: 10
}

int main()
{
  Player_Stats pStats;

  aFunction(pStats);

  cin.get();
}

Originally Posted by major_small

generally you should try not to create things globally... if you really wanted to, however, you could also do this:

Code:

class Player_Stats
{
  private:
    USHORT itsLevel;

  public:
    Player_Stats():itsLevel(0) {} //constructor, initializing itsLevel variable to 0

    USHORT GetLevel() const { return itsLevel; }
    void SetLevel(USHORT level) { itsLevel = level; }

} pStats;

also, I just noticed that your class was missing a semi-colon.

Declaring Class Player_Stats { } pStats; is exactly the same thing as declaring it later (its global either way), its only seperated I think.

Yeah I just noticed that semi-colon too, and was about to edit when I saw this post.

nono I know it's still global, I was just pointing it out to you in case you didn't know you could do it that way.

well, you'll need references and pointers, and in this case you kinda have to use them (unless you want to use Dae's approach), but some ways are just easier than others. like in my case, neither are really much 'better' than any other (even though that's debatable), some are just easier on the brain to think about.

and about the player and human subclass, you should look into inheritance. that's exactly what you want there. basically, you could create a human class, and a derived player class that, like you mentioned, extends the human base class. the player class would have all or most of the methods from the human class, plus some of it's own.

Originally Posted by muggizuggi

And Dae, thanks for trying to help out!
That was exactly what I wanted when I came here, but since it seems to be considered bad practice, maybe I should try an other route?

Would that be the clever, expandable, reusable OOP way of the wise?

It isnt bad practice, in this case. The fact that your entire game revolves around your Player makes pure sense that you would create your Player class object globally. Using either method will not result in extra memory used or problems, but makes the code read differently.

However, even though I suggested that.. I agree with Major, I would use references (or pointers) just because it makes the code easier to read, so anyone reading it knows where things are coming from. I believe the reason I even recall using that method is because I did win32 API programming when I didnt know how to work with multiple files, OOP, or inheritance well enough that I had global objects and used 'externs'.