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?

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