Wow, 7 answers already, with lots of good info! Many thanks to all of you.
I will try to answer all of you, and implement any correction I feel I understand.
Lets start from the top:
c+noob:
Quote:
i know enough to still provide a destructer because sometimes its a good hbit to make
ex.
static constructor();
virtual ~constructor();
Hmm... You might be right, sadly I don't know the key words static and virtual. Do you maybe have a link to some good info?
major_small:
Quote:
as for your logic/etc., I haven't taken too much of a look at it, but I did find this spelling error (you missed the last 'h' on health)
Ugh! A bug! I found an other one myself: "sheriff" was spelled "sherrif".
Both bugs have been fixed, and the source code compiles much better now! Thank you! ;)
Seriously though, when I am making a program that outputs text to the user, I really do appreciate being notified of any such spelling errors.
So thanks again.
Dae:
Quote:
Not a bad start...
Why, thank you!
Quote:
Well first since you are making the player class derived from the human class, you should make a deconstructor in the player class, and set it to virtual: virtual ~human() {}.
Sounds interesting. Unfortunately, I have absolutely no knowledge of the keyword virtual. What does it do?
Quote:
Also.. the compiler does set a default constructor and deconstructor, but neither do anything, so dont expect the default deconstructor to pick up after you.
Does that mean that the default destructor does NOT free the RAM that the object resided in? And I suppose you mean that the constructor doesn't do anything, besides constructing the object from the class? Or is that a misunderstanding?
Quote:
I'm not going to look over the actual coding of how you made the dice roll, or why you are setting dice[numberOfDice]=0; at the end of the function, and just concentrate on OOP concept.
The answer to the mystery of the insertion of the zero, lies in the sayDice() method. It uses the zero value to determine when there are no more virtual dice in the dice[] array to read. That is also why it is set at dice[0] in the constructor, because there are no dice to read.
Quote:
OOP is Object Oriented, so thats the working with objects, not the 'doing everything in the game inside of objects (classes)'.
OK, so that means that the term "OOP" is more open, and not really confined to "doing everything that relates to the actual program inside seperate objects"?
Quote:
Your start game and end game functions would make more sense outside of the player class, why not to because 1) its a bit pointlessly confusing, and 2) the object of the player larger in data, which may not be good in theory if you make more objects of player.
That's what I'm looking for. Especially number 2), I imagine, is important when trying to develop good habits.
Quote:
In your function: int rollDice(int numberOfDice, int sides), I believe you meant to do: if (numberOfDice>9), before you cout....
That is exactly right. It has been corrected in my working code, Thanks!
Quote:
Why are you using getche(); if you dont like it then?
Good question... I guess the reasons are, that I used it in a calculator I programmed earlier, and it was the only on I knew, besides cin.
Quote:
If you have not taken in data using cin <<, then you can simply use cin.get(); to pause. But if you have taken in data using cin <<, when you want to pause use:
cin.ignore();
cin.get();
Cool! Is there maybe a tutorial somewhere, about how those functions work exactly? Maybe cin has more functions?
Quote:
You're using some headers that may become deprecated in the future, because they are meant for C, not C++. <iostream.h> should be <iostream>, and you forgot the line: using namespace std;. I'm not sure but I think <stdlib.h> should be <cstdlib>, and I'm not sure about the rest. Headers without .h are meant for C++, headers with .h are meant for C or C++, as some .h's dont have no-extension versions.
2 down, 2 to go then. I don't count the <string> header, as I believe it is good. Do you know of a good source of info on what headers to use?
Quote:
Generally coding style is to capitalize class names..
What do you mean? Should I call the "player" class "Player" instead??
Quote:
and if the function inside of a class is as long as yours are, to seperate it from the class, then use the syntax: type class name::function name (), below the class. Doing this you can seperate the class body and put it in a .h, then #include it into a .cpp where you have the functions using that syntax.
Noted! I am shure I saw a thread on making includes a few days ago... Will take a look.
Quote:
Oh and its not exactly player.rollDice(), its player::rollDice().. thinking about it that way will help.
That would be when I write to other programmers, and otherwise right? Because the program won't compile if I try to call a method like that...
Quote:
Last note.. it seems like you are trying too hard to make use and example using OOP. Put methods that make sense in with classes that make sense, you probably shouldnt just throw in your dice method into the human class just because you're dying to throw something into it. If you're just using it as an example of how to override methods of base classes, alright cool.. but otherwise the player class would usually contain health, stats, what to do when taking damage, etc. and not gamestart, gameover, rolldice.
Sure, you are right. I am trying much too hard to cram stuff into that class. However, I did seriously consider giving each character in the game his own set of dice, but even so, I definitely shouldn't write it directly into the human class, as dice are not a part of the human anatomy.
Not even digital speciments. ;)
Please correct me if this is not right, or something seems unclear.
Quote:
Also when coding try it make it readable, which falls under 1) splitting up the class from the long methods, and seperating them into the files, 2) good tabbing/spacing, which you do have, 3) good, consistant coding style, well yours is half way there.
1) I'm working on it. 2) Thanks alot! I put a lot of effort into it. 3) Any tips would be appreciated!
Quote:
I would recommend using a common coding style for all of your code, but that may be a little bit to take in right now, if not I'll paste it, its about naming your variables, classes, objects, and functions, I've noticed it in code, and read it in books.
Sure! Let me at it! If it is too hard to handle, I can always put it aside, but I have a feeling that something like this would be smart to do, right from the start.
quzah:
Quote:
Any elements of an array which you do not initialize, provided you have initialized at leats one of them, will be set to zero. Thus:
Code:
int foo[ BAR ] = {0};
Does that mean that if I declared the dice[] array like this:
Code:
int dice[10] = {0};
all the cells in the dice[] array would initialy be set to 0?
Dae again:
Your second post clears up a lot about how to structure my classes and (along with quzah's post) makes me realize that I need to read up on arrays.
nvoigt:
Quote:
Your "dice" problem results from the fact that the class variables default modifier is not protected, but private. Private variables may not even be accessed by derived classes.
Thanks for clearing that up! It is misunderstandings like this that I really want to avoid, right from the start. If you see anything else in my comments, that is wrong or just seems unclear, please let me know!
Quote:
I'd suggest always putting a qualifier before a block. If you want something to be private, put a private:, if you want it public or protected, put that above the block. Makes it easier to read, too.
That seems like a very sensible practice, and I will try to incorporate it right away.
Also, I call it "protection level". Is qualifier the correct term for that?
As to your suggestion on defining the dice in its own class, I might do just that. Although, I am still very unshure as to how the whole thing will be linked together.
Humongous post again, but a lot to anwer too. Thank you all for making an effort to assist me! I really appreciate it!
I will include a short todo list:- Read up on arrays (resize).
- Stripp unwanted features from human class.
- Sepparate long methods from class body.
- Read C Board on making header files.
Once again, if anyone has any suggestions or additions.... You know what to do. :)