Help with C++

I'm learning how to write a roguelike, and it's pretty much the first real programming project i have ever done. I have studied C++ for a bit at school and on my spare time, but i know only the basics, and i thought that programming a simple game would be good learning. I'm trying to make a character creator where you choose a race and a class, then the program rolls your stats, adding different bonuses based on classes and races, but i run into this error:

100 C:\Dev-Cpp\char.c statement cannot resolve address of overloaded function

I'm trying to write the stats to a simple text file, but the program tells me that. What gives?

POAST MOAR SAUCE !!!!!

Ok, i know the code sucks major amounts of ass, bear with me:

char.c contains this:

#include <fstream>
#include <iostream>
#include "char.h"

int clear();

int stats();

int main()
{
    character creating;
    cout<<"Creating a new character, choose a race:\n";
    cout<<"1.) Mutant\n2.) Robot\n3.) Human\n";
    cin>>creating.Race;
    clear();
    cout<<"Choose a profession for your character:\n";
    cout<<"1.) Brute\n2.) Gunslinger\n3.) Scientist\n";
    cin>>creating.Class;
    clear();
    cout<<"Choose a name: ";
    cin>>creating.name[256];
    stats();
}

int clear()
{
    system("cls");
}

int stats()
{
    int e = 1;
    int r = 2;
    int t = 3;
    character creating;
    srand((unsigned)time(0));
    if ( creating.Race == e ) //1 is mutant.
    {
         character creating;
         creating.Str = (rand()%5)+(rand()%5)+18;
         creating.Dex = (rand()%5)+(rand()%5)+10;
         creating.Int = (rand()%5)+(rand()%5)+5;
         creating.Tou = (rand()%8)+(rand()%8)+15;
         creating.Sen = (rand()%6)+(rand()%6)+6;
         creating.HP = creating.Str/3 + creating.Tou/2 + (rand()%10);
         creating.SP = creating.Int/2 + creating.Sen/3 + (rand()%10); //sum is 64
    }
    if ( creating.Race == r ) //2 is a space robot, protecting you from the secret of space.
    {
         character creating;
         creating.Str = (rand()%6)+(rand()%6)+6;
         creating.Dex = (rand()%8)+(rand()%8)+15;
         creating.Int = (rand()%5)+(rand()%5)+10;
         creating.Tou = (rand()%5)+(rand()%5)+5;
         creating.Sen = (rand()%5)+(rand()%5)+18; //64 here too
         creating.HP = creating.Str/3 + creating.Tou/2 + (rand()%10);
         creating.SP = creating.Int/2 + creating.Sen/3 + (rand()%10);
    }
    if ( creating.Race == t ) //3 is a MUNDANE HYOOOOOMAAAAN.
    {
         creating.Str = (rand()%5)+(rand()%5)+13;
         creating.Dex = (rand()%5)+(rand()%5)+13;
         creating.Int = (rand()%5)+(rand()%5)+13;
         creating.Tou = (rand()%5)+(rand()%5)+13;
         creating.Sen = (rand()%5)+(rand()%5)+12; //And here too, gotta be balanced mon.
         creating.HP = creating.Str/3 + creating.Tou/2 + (rand()%10);
         creating.SP = creating.Int/2 + creating.Sen/3 + (rand()%10);
    }
    if ( creating.Class == e ) //Brute
    {
         creating.Str++;
         creating.Tou++;
         creating.Int--;
    }
    if ( creating.Class == r ) //Gunslinger
    {
         creating.Sen++;
         creating.Dex++;
         creating.Str--;
    }
    if ( creating.Class == t ) //Scientist
    {
         creating.Int++;
         creating.Tou++;
         creating.Dex--;
    }
    ofstream a_file ( "character.cha" );
    a_file<<"Character data, do not edit\n";
    a_file<<creating.name[256]<<"\n";
    a_file<<creating.Race<<"\n";
    a_file<<creating.Class<<"\n";
    a_file<<creating.Str<<"\n";
    a_file<<creating.Int<<"\n";
    a_file<<creating.Dex<<"\n";
    a_file<<creating.Tou<<"\n";
    a_file<<creating.Sen<<"\n";
    a_file<<creating.HP<<"\n";
    a_file<<creating.SP<<"\n";
    a_file<<"End of file";
    a_file.close;
    cout<<"Creating complete!";
}

char.h contains this:

#include <cstdlib>

using namespace std;

class character
{
      public:
             char name[256];
             int Race;
             char Class;
            
             int Str;
             int Int;
             int Dex;
             int Tou;
             int Sen;
            
             int HP;
             int SP;
             };
            

lol... line 100 should be "a_file.close()"

Oops. :D

Also... this error message demonstrates why operator overloading is somewhat evil. It is looking for a overloaded function for the member access operator to pass close as an argument to it. That and FFS, it's kind of stupid to allow for such a fundamental operator for the language to be overloaded.

MODS /B/ IS NOT WORKING PLZ FIX CUZ I LIEK /B/. KTHNKSBAI.

replace "char name[256]" with "string name", and thank me for the time it took to read your crappy code.

>>3
YOUR CODE IS LIKE LIQUID PAIN FLOWING THROUGH MY ARTERIES

    a_file<<creating.name[256]<<"\n";
you mean creating.name, i think. [256] is the 257th character, which does not exist...

Aggggghhhh thats not how you use arrays....
All of that creating.name[256] stuff will just try to input/output one char from the memory address creating.name + 256 like >>10 said, which is outside the bounds of the array.

Just use strings like >>8 said, with getline() to take input, because you aren't skilled enough to deal with inputting to arrays while handling possible buffer overflows, etc.

Number 3 is going to be crushed by a wall of code if he doesn't organize his project soon. Please learn how to use multiple source files at least.

>>12
If he's having trouble just dealing with input, I don't think his project will ever get far enough to have to worry about organization.

>>3
PROTIP: system("cls") won't work on anything except Windows's sorry excuse for a terminal emulator (well, maybe some versions of DOS, but I doubt you'd have to worry about that in your userbase). Observe:

$ cls
-bash: cls: command not found

The world would be a much better place if every programmer remembered that not everyone uses the same operating system/browser/compiler/terminal/editor as they do.

Making data members of classes public is evil. Never do it (unless you're making a collection of data like the char_traits template that basic_string uses, or something else fancy). Write accessor and mutator functions instead. Rule #1 of object-oriented programming is to keep the internal states of all your objects consistent.

Use std::endl instead of newline, because endl flushes the output buffer.

As three or so people have suggested, use the string class; it'll save you countless headaches.

>>14

That's asinine! How the fuck am I supposed to share data between different classes?

>>15
Message passing.

>>15
If you don't use data hiding, every single piece of code that uses that class will know how its data is stored and access the data directly.  If you suddenly need to change how the data is stored in the class, all of the other code will need to be changed too.  If it is a large project, you are fucked.  This was what caused the whole y2k thing.

This was what caused the whole y2k thing
lolwhat

This was what caused the whole y2k thing.
i didn't think OOP and classes and all that shit were even invented when the decisions that led to the y2k problem were made.

You also forgot to return 0 at the end of main.

Also, it's better to pass the character object as an argument to the function stat instead of relying on that the object stil exists within the stat scope.

Example on how to share data between classes:


#include <iostream>
using namespace std;

class Cnum{
private:
int a;
public:
void set(int i){a = i;};
int get(){return a;};
};

int main(){
Cnum no_one;
Cnum no_two;

no_one.set(10) //sets the int a to 10 inside the object no_one

no_two.set(no_one.get());// sets no_two's a to no_one's a.

cout<<no_two.get()<<endl;

return 0;
}
This way makes sure that you dont access your class varibles by accident.

>>19
You don't need classes for data hiding.  My point was that the date was stored in two characters, and everything that accessed the date directly read these two characters.  So when someone went to fix one of these programs, they couldn't just replace the two characters with an int, they had to change every piece of code that accessed the date.

You also forgot to return 0 at the end of main.

Also, it's better to pass the character object as an argument to the function stat instead of relying on that the object stil exists within the stat scope.

Example on how to share data between classes:


#include <iostream>
using namespace std;

class Cnum{
private:
int a;
public:
void set(int i){a = i;};
int get(){return a;};
};

int main(){
Cnum no_one;
Cnum no_two;

no_one.set(10) //sets the int a to 10 inside the object no_one

no_two.set(no_one.get());// sets no_two's a to no_one's a.

cout<<no_two.get()<<endl;

return 0;
}
This way makes sure that you dont access your class varibles by accident.

i fail a slow doublepost

Just use a language with support for property, so you don't have to write a shitload of getters & setters.

*properties

(eg. C#, Delphi)

i dont get why people try to hide class variables at any cost. of course its wise to hide as much variables as possible, but why writing a shitload of getters and setters instead of simply calling the variable itself.

>>24-25

pfft... real men don't need refined syntax sugar like properties.

>>26
Read >>17

>>26
because fugly syntax is better style.  the only reason you would call a 'setX()' is if you want to set an X value.  the only reason you would call a 'getX()' is if you want to get an X value.  the ugliness forces you to be sure you actually want to set/get an X at the time.

if (someClass.X = 5) { someFunction(); } would compile, but likely not work as expected.  also can be a bitch to debug.  whereas:
if (someClass.getX() = 5) { someFunction(); } would give a compile-time error.

this is a good thing.

>>24
Just use a language that's powerful enough to write code for you, then you can tell it to write your getters/setters.

Fix'd.

>>29
you can define getX() as "SomeClass & getX() { return x; }" and the expression "getX() = 5" works perfectly.

>>31
Returning a reference to a variable in the class defeats the whole point of having data hiding, since then whatever uses the getX() function will know how the data is stored in the class.  If the data type of x changes, everything using getX() would have to be changed.

>>31
Oh, and if you were gonna give some bullshit about converting x to the old data type in getX() and then returning that, everything would fuck up because the local variable would be deleted when the function returns.

>>32
It's even worse than this; now you can't provide any special functionality in setX(), because using getX()= circumvents it. Your variable is as good as public.

>>32
You can declare the reference const, so it can be read but not changed. >>33 is a problem, although it could be circumvented by creating the variable off the heap (but then you have to take care of destroying it sometime).

>>35
Doesn't matter if it can be changed it or not, the point is that there is no data hiding that way.  haha, and I don't think it is a good programming practice to expect whatever calls your function to also deal with cleanup of the memory it allocated.

>>20,22
Declaring variables private and then using getters and setters to use them is not data hiding.  You risk breaking encapsulation by coding shit like that usually, and in your examples there is no reason why Cnum can't be a struct.

>>36
True, although you can have the variable belong to the object and take care of creating and destroying it (basic_string does something like this for c_str() and data()). Basically, the question is, which method is the most efficient? If the value's being accessed constantly, it may be cheaper (especially with compiler optimizations) to create one variable and return references to it.

Getters and setters are nice for regulating variable access in multithreaded programs, so threads don't end up reading and writing to the variable at the same time

>>39
You write concurrent code in a language that doesn't have built in support for concurrency?

Oy.

>>37
Usually people make a statement and then explain why they believe that statement to be true.  Declaring variables private and then using getters and setters to use them is data hiding.  You do not risk breaking encapsulation by coding shit like that.  There, I just refuted your argument.

OH SHI--

The reason I believe that getters and setters are usually bad is because they don't really do anything specific with the member data. Think about, for instance, a string class. In a particularly well coded implementation, you can't necessarily access where the string itself is stored (perhaps like a character array or a stream) like you would with getters and setters, but you can work through the interface to do what you want. That's data hiding.

If you realise stuff like Cnum is really just a data structure, you can spend less time coding unnecessary functions.

>>42
Yes, I agree that having getters/setters that do nothing other than allow direct access to the variable are retarded.  However, there are tons of uses for them, like only writing a getter to make the variable "read-only".  In the case of Cnum, the setter could clamp the value passed to it to a 0..255 range to provide a cap for the stats.  Also, getters are often used for array access, to make sure the index is in-bounds (Most of the standard c++ classes have an at() function that does this).

>>43
Yes, I agree that having getters/setters that do nothing other than allow direct access to the variable are retarded.
No, goddammit. How stupid are you people? Getters and setters properly separate interface from implementation, so that if in the future you need to change the implementation, you won't also have to change all of the code that uses the class.

>>42
Of course you shouldn't just write getters and setters for everything contained in the class, only for that which would otherwise best be a public variable. In your string class, you don't have a public char array, but getCharAt and possibly putCharAt methods.

>>44
This is exactly correct.

Yes, you should absolutely be writing get and set methods even if they do nothing other than allow direct access. This encapsulates the implementation from the interface; if you decide to change it later on, like my Shape/Triangle example earlier, you don't have to go running around on a wild goose chase through all your code to change to the new implementation.

It gets even worse than this when you're not actually changing the implementation, but rather adding some static behaviour to modify the variable being set. For example, doing bounds-checking, or simply printing the variable being set for debugging purposes. You'll have no warnings if you forgot about some access to the public variable.

Yes, I agree that having getters/setters that do nothing other than allow direct access to the variable are retarded.

I hope I never end up working on a project with someone who has this mentality. I don't want to be the guy who has to stay up till 5am debugging your code when I could have just slapped cout<<x; in your fucking setX method and been done with it.

problem: you want to be able to change the behavior of getting/setting a value in your object.

idiot solution: force everybody to use method calls rather than the language's built-in assignment and access syntax. write about 4 times as much code that does absolutely nothing extra except possibly use more CPU time for the method call.

non-idiot solution: overloaded get/set operations.

>>46

WE HAVE A WINNER!

>>46
idiot solution? oooohhhhh two opcodes added for each function call on a 1GHz CPU? Holy overhead Batman, no one cares!!!

It should be mentioned that if you are using get/set operations, you should examine the structure of the program to make sure they are necessary.  For example, the OP should make a constructor that is in the format character(race,class,name), then the first part of stats() that generates the statistics should be in the constructor body, and the output part of stats should perhaps be in an overloaded operator<<.  Then the getters/setters are not even necessary and THIS ARGUMENT IS POINTLESS LOL.

>>46
non-idiot solution: overloaded get/set operations.

What the fuck? How does that make any sense?

Say I have a Shape object with public floats: angle, x, y. What the fuck do you plan to overload to access those?

>>46

Overloading operators is more code than get/set methods...

>>48
>>50
>>51

Thread over.

>>52
We still haven't heard back from >>46 about these "overloaded get/set operations" he was talking about, thread must resume.

>>37,42 me.

I make a simple suggestion and it explodes into an argument about whether getters and setters are good for you. I make the case that they aren't, because there are smarter ways to represent an object than a bunch of "private" variables with getters and setters. It seems that >>49 agrees with me.

Now, following any practice all the time is going to prevent you from doing anything productive. The difference is that
In your string class, you don't have a public char array, but
getCharAt and possibly putCharAt methods.
This is something relevant to the problem domain that the string class is there to solve; it may be implemented like a getter/setter, but it isn't "bad" per se.

But the code that I originally had a problem with:

class Cnum{
   int a;
public:
   void set(int i){a = i;};
   int get(){return a;};
};

If you do this, learn better habits: that's just fucking enterprise code. It might as well be a struct.  You guys are all taking a simple statement as a doctrine for principles.
  

lol Toy Language

beware the army of 12 year old autistics

Bringing /prog/ back to its people
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy