Quote:
but would 'object.x=5;' be faster than 'object.set_x(5);' if it was looped say...987 thousand times per frame for some reason?

Todays optimizing compilers would probably recognize and inline the set_x function in that particular case. You can read more about inline expansion here

Quote:and I've seen several tutorials that go back and forth between private and public declarations, but that always seemed frivolous to me.

If you just mean that switching back and forth between public and private multiple times seems frivolous, then that's just a stylistic choice. There's no requirement to do it that way, and you can certainly just have one public section and one private section if you prefer.

If you're saying that use of public and private seems frivolous in general, then I take it you haven't yet been convinced of their usefulness :)

Quote:For that specific example of privatizing the screen surface, nothing would change other than possibly losing the ability to draw on the screen from some random function, but then what is the value of that restriction?

Part of the problem is that if you can draw to the screen from some random function, then eventually you or someone else probably will draw to the screen from some random function (most likely because it'll seem convenient at the time). If you take this approach throughout your code, you may end up with a convoluted mess whose interdependencies are difficult to keep track of. Modularity and reusability will suffer, and it'll become harder to make changes to the architecture.

Quote:I understand that not allowing certain chanegs to protect things is good style, but if the programmer intends to change whatever it is that they are being blocked off from wouldn't they simply find a way to do so?

Ok, how would you do it? How would you go about modifying a private member variable from outside the class?

Also, keep in mind that even in real life there are plenty of examples of safeguards that can be circumvented if desired, but nevertheless provide increased safety and security. A lot of the safeguards we put in place (both in real life and in software development) aren't intended to prevent people from doing things (which is often impossible), but rather to deter people from doing things.

Quote:Also, on direct variable setters/getters, isn't having a private variable, 'x' as well as public 'get_x(){return x;' and 'set_x(arg){x=arg;}' functions essentially the same as making 'x' public to begin with?

Yes, many would argue that having a getter/setter pair that doesn't do anything but 'get and set' has little point, and you might as well make the variable public. Furthermore, getter/setter pairs are generally discouraged in object-oriented design anyway, as they tend to expose implementation details and make the interface less abstract.

I've always been bad with stylized things without clear tangible benefits/costs to compare, so I have a feeling that I might end up with bad coding tendency for the sake of personal convenience...but I can't think of anything anyone could say to affect that so...

Are there any direct processing speed differences between private and public members? I can't think of a reason for there t be...but I can't think of a lot of things.

Also, quick unrelated question, what is the significance of terminating float values with 'f' such as '8.0f' and the like? Does it save memory instead of recording extra zeros?

Thank you, swiftcoder.

Quote:Original post by Windryder
One theoretical benefit of using get/set "proxy" functions is that by hiding the implementation details of the class, we're free to change how the value is set or retrieved without breaking client code. Consider the typical example where we might some day decide to retrieve a field from a database rather than simply return a stored value.

Right, but notice I said a getter/setter pair that "doesn't do anything but 'get and set'". By this I meant that the getter and setter don't do anything 'extra'; no checking of values, no preserving of invariants, no converting to or from some alternate internal representation. (I realize though that I didn't make this completely clear.)

Quote:Original post by wioneo
I've always been bad with stylized things without clear tangible benefits/costs to compare, so I have a feeling that I might end up with bad coding tendency for the sake of personal convenience...but I can't think of anything anyone could say to affect that so...

Well, nobody's saying you have to write object-oriented code. If you already know you prefer a procedural approach (or a mix of procedural and object-oriented techniques), just go with it.

That said, I think it's worth considering what other, perhaps more experienced coders have to say (and here I'm not talking about myself, but rather about experts in the field and the many experienced coders who frequent this forum).

The benefits of the practices under discussion here won't necessarily be evident immediately, nor will they necessarily be evident in the context of small, one-person projects. As such, if you determine that you'll only adopt practices that have immediate, tangible benefits in the context of whatever project you're working on at the moment, you might, as you say, end up developing some bad habits as you progress.

But as I said, you should probably just go with whatever makes the most sense to you. As you write more code and as your projects become more complex, you may start to see how some of the object-oriented techniques under discussion here can be beneficial, and if so, you can always incorporate them at that time.