Quote:
First, and most importantly I think, what is the purpose of declaring any members of a class as private?
Making something 'private' is part of encapsulation. You can make getters/setters to access private members, and do error checks on the values being set. This is better than having a plain variable there.
Private members can't be accessed directly from the outside, this lets you hold invariants true in your code. If 'int foo' is public, you can't assume anything about it. If it is private, you control all access to it, and can safely write code that makes assumptions about its value. For instance: a public "int *foo" has to be error checked for foo being NULL before every function that uses it. A private "int *foo", you'd know exactly at what points in time it is or isn't NULL, since you control exactly where it gets set.
Quote:
but isn't the best way to prevent that to just...not referrence them?
Since private members can't be accessed from outside, OTHER PEOPLE using your code will know that those variables and functions are 'internal' and know not to use them. If everything is public, the assumption will be that those variables are free to access. You might know not to access them, but making them private insures other people know the access pattern.
Quote:
Having certain members be inaccessible seems, more of a hinderance than help to me.
You might have too much data in your classes. You might have too much or too little obligation to your classes. If you think everything needs to be public, you need to better define the boundries of where that data is useful to you. If you end up with a lot of "GetHP" "GetAP" "GetMP" functions floating around, try to encapsulate further to a "GetStats()" that returns a collection of related values.
Quote:
Does 'else' consume any resources?
nope.
Quote:
Does variable length affect anythign at all?
It doesn't affect the runtime performance of your program. Having well named variables helps in readability too much to be ignored.
Quote:
if (5==5)
{return true;}
...less efficient than...
return (5==5)
no. and even on the off chance that it is (maybe in debug mode), it isn't worth making micro optimizations like that when they affect the readability of the code.
(aside: they both result in 'return true;' because (5==5) can be proven true at compile time.)
Quote:
Secondly, what is the purpose of seperating a function into a prototype in one file and then defining it in another file as opposed to just defining it as part of the prototype? This just seemed to add a small amount of unnecessary work...
1) Compile time. Including a header file pulls in the entire header. If you have a lot of code in your headers, it takes longer to compile. Putting the prototype in the header reduces the compile time for all files that include the header.
As well as the fact that changing a include forces you to recompile everything that included it. By seperating the definition and declaration, you can make edits to the functionality of your code without incurring that huge recompile.
2) Dependences. If 'foo' can call 'bar', and 'bar' can call 'foo', then you can't actually declare the functions without getting either 'bar is undefined' or 'foo is undefined'. By having a seperate prototype section, you can tell the compiler about 'foo' and 'bar' so that it knows they exist, even if it hasn't seen them in full yet.
3) Readability. Looking at a prototype section, I can explicitly see all the functions I have available. In the declaration section, all the functions take up a lot of room, and even folded, it isn't quite as easy to read through.
4) Similar to the public-private thing, you can put some prototypes in the header, and leave the more internal ones in the .cpp file.
note: code tags do preserve formatting, and give your code a different font. For better formatting, and colors, use the source tag.
