I just wanted some peoples' opinions on what they thought about the proper way to organize classes when programming games in C++. In all the classes I've taken, the instructions were always "all variables and some functions should be private, and only other functions should be public. However, in games, do you think it matters to make an object's world position public, so that it can be quickly accessed during the game without having to make a function call as opposed to making Get/Set functions that do the same thing? After all, many people program games in straight C, which uses no classes at all. I was just hoping to get some peoples' opinions on this, as I am a relatively new coder when compared to most programmers, and I'm trying to avoid bad programming habits.

I think get/set functions are a good idea, you should have them inline meaning they'll be no overhead using them at all just like if you'd accessed them directly (unless your compiler really sucks). The advantge of get/set functions is that if you decide to alter how something is represented inside a class you only have to change the get/set functions and not every piece of code that uses the class. A good rule of thumb is that when designing a class it should made it such a way that if you want to alter how something works within the class, code that uses the class should not have to be altered.

There are pros and cons of all methods. Pick one that suits you and that you consider to be maintainable/sustainable. There is no "best", except in your head :-P

Personaly I don't use get/set methods, however, I have never made a really big project. Everytime I try get/set they quickly start to annoy me. While in theory you may want to do something special to happen when you access a variable, it rarely happens in practice.

I've readed somewhere paper by Stroustrup himself where he says that overuse of getXXX/setXXX thingies sometimes may be a sign that something is going wrong. As i understand he mean that if you need many get/set things, you aren't working with class from outside as with highter abstraction level than it's components, and it's not good, and get/set is not a solution...

it's not an issue with Delphi, where you have "properties" that can be mapped to variables or to function, and you can swich to using properties at any stage of work, when you'll think it's needed.

edit: but i would prefer get/set things for my "CoordSys" class , so i will be able to cache matrix it corresponds to and do some other optimizations.
(my CoordSys class contains one 3-vector and one quaternion, and among other things have functions like "GetTransformTo" and "GetTransformFrom" that returns 4x4 matrices. So i'll be able to automatically cache that matrices, and will improve speed at little typing cost.)

Quote:Personaly I don't use get/set methods

Maybe that's what I was trying to get at -- how many people actually make use of get/set methods. They sound like nice ideas, but whenever I write them, they're usally just returning a variable (which I think is the point). Maybe its that I'm just lazy and think that less typing is easier, so I often just make variables public, and access the variables directly in other files.

Quote:Original post by wyrzy
I just wanted some peoples' opinions on what they thought about the proper way to organize classes when programming games in C++. In all the classes I've taken, the instructions were always "all variables and some functions should be private, and only other functions should be public.

However, in games, do you think it matters to make an object's world position public, so that it can be quickly accessed during the game without having to make a function call as opposed to making Get/Set functions that do the same thing? After all, many people program games in straight C, which uses no classes at all. I was just hoping to get some peoples' opinions on this, as I am a relatively new coder when compared to most programmers, and I'm trying to avoid bad programming habits.

Unless your compiler is absolutely horrible, your function calls should be inlined and will be equally as fast as accessing public data directly.

I wrap up everything in classes when I use C++, and my C++ code is almost always faster than the equivalent C program. I never use public data.

To write fast code, you must write flexible code. If your code is flexible, you will be able to optimize it much more effectively later on. You will always be able to optimize flexible code. If you used global variables all over your program because you thought it would be faster (even though it is not), then you will have an absolutely horrible time trying to optimize because your code will be so rigid.

You must first get something working correctly, written in a flexible way. Then benchmark and profile and prove to yourself what needs to be optimized. Now you can optimize effectively since you know what parts need it, and you have written flexible code that will allow easier modification.

This is the best advice anyone has ever given me on writing fast code. I'm going to be late to work for taking the time to write this, but it's important [wink]

Quote:
Never, never, never, never, never optimize a program before it is working correctly. And when I say never, I mean not ever.

The only exception to this rule is in the choice of algorithms. There is no sense in picking a bad algorithm to start with. And even if you did happen to pick the wrong algorithm, then it is not hard to change it.

Premature optimization does absurdly more harm than good. For every ounce of benefit, there are a trillion gallons of downside. When you start programming ANYTHING, write clear, simple code that best expresses the algorithm in the most straightforward manner.

Now, let's go farther. Suppose that you have chosen some fundamentally bad data structures. If your program is written in an abstract enough manner, it won't matter. And the more abstract you make it, the less it will matter.

My point:
1. Write clear code
2. Choose good algorithms
3. Write abstract code that hides the implementation details when possible
4. When everything works well, profile it.
5. Speed up the stuff that will benefit from it.

Quote:Original post by wyrzy
However, in games, do you think it matters to make an object's world position public, so that it can be quickly accessed during the game without having to make a function call as opposed to making Get/Set functions that do the same thing? After all, many people program games in straight C, which uses no classes at all. I was just hoping to get some peoples' opinions on this, as I am a relatively new coder when compared to most programmers, and I'm trying to avoid bad programming habits.

Before you start thinking in terms of public data vs. simple accessor/mutator, think:

Why do I want to know this object's world position? Why can't it just react to its environment?

Why do I want to tell this object its world position? Even if it can't be responsible for moving itself, maybe I should just be telling it which way to move, and let it make the attempt itself?

For collision detection, you'll want to know the positions of at least two objects, the code that does the collision detection will have to get the position of at least one of the objects, no matter where the code is located.