davepermen

What's your take on protected variables?

In the context of c++, it seems most experts (Scott Meyes, Herb Sutter) think is not  a good idea. I don't agree. In fact, some languages, for example Ruby, have only automatic protected variables.
It seems silly to make a 'setter' and 'getter' functions for a variable when the derived object is employ in terms of "is-a". Also, making 'setter' functions opens the variable to be manipulated from outside the object! Of course, one could make in the 'setter' protected, but isn't that 'running in a loop'?

Please, discuss.

EDIT:

Let's say I have:

[source lang="cpp"]class Shape{public: virtual void CalculateArea();private: //private! int x, y; int width, height;};class Rectangle : public Shape{public: void CalculateArea(){ /* I need width and height to calculate, but can't access it. What can I do? */ }};[/source]
If I make 'getters' for Shape class:

[source lang="cpp"]class Rectangle : public Shape{public: void CalculateArea(){ get_width(); //isn't this silly, as width is a fundamental part of Rectangle //also, now everyone knows my width! }};[/source]

the problems with getters and setters is, people take them too literally.

they make a get and set for each variable, allowing users to, again, invalidate state.

your rectangle class needs left, right, width, top, bottom, height, area, aspectratio, etc to be publically accessible. and none of those getters/setters/whatevers should make it possible to have an invalid rectangle, ever.

set_width() can check if you enter a negative width, and prevent it. set_right can check if your right is more left than your left, and prevent it. and vice versa.

it's not about making methods that directly expose your variables in public. if you want that, use public directly. getters and setters is about NOT exposing anyting directly. aobut making SMART getters and setters. in that case, about making a rectangle ALWAYS a rectangle. not something that has negative space, or what ever.

and as having an object valid at all time is very important, public variables are dangerous. as are protected ones.

but forget about getters and setters. don't write a car that has get_position and set_position. write a car that can drive(), turn(), break() and return current_position(), current_orientation() instead.

if you expose your variables directly, you did not understand the idea of getters and setters.

METADATA:

There are many times when a program needs to store and reference data that is a result of processing and that can be used again. How will you store metadata? I like to use singletons for structural/constant data/flags/metadata(temporary) instances, when the complexity of creating new instances and having it loading its data from something/somewhere doesn't worth as simply acessing it straight like cache of processors is used and Windows Registry (always in memory).

I just use an ordinary class for this. And if at some point i need multiple different resources, I can just do that. If i don't, I don't. That's the point: LIMITING YOURSELF doesn't help you later. It will BLOCK you later. Without ever having given you any gain. You want just one: Instanciate just one. You want global access? Make it a global. Don't try to hide it behind some fancy terms. Be honest to yourself.

the streering wheel example shows that some people don't understand what a class is for, and what an object is for.

class SteeringWheel {
}

class Car {
    SteeringWheel steeringWheel;
}

classes are not what defines how many exists of something. that's the objects job.

if a singleton would fit my needs, i would use it. but it NEVER ever did. it's just a) limiting and b) making code look ugly. and, most importantly, c), it NEVER makes sense.

heard that from too many languages. but, we'll see.

define is just a text replace, and does not care about the language. that can lead to some interesting abuses, and some interesting uses (the header include once thing). other than that, use language features, as they don't want to bite you in the back.

like #define max did all the time for me...

if you don't plan to ctrl-r replace-all-text, don't use #define.

And there you see for yourself the wrong way of thinking that is the singleton drug: See all the bad things.

Guess what? For multiTOUCH, that mindset had to change (example in win8: with one finger you chose a tile, with the other you move the full screen below that tile to quickly bring it to a new place). so would it had to change for multimouse, obviously.

and yet, all the games and apps on multitouch devices don't HAVE to care about multitouch if they don't want to. but they CAN

and THAT, sir, is the POINT.

SINGLETONS RESTRICT POSSIBILITIES.

THAT
IS
NEVER
A
GAIN

NEVER.

i gave you multiple examples by now, and yet you just don't get it. it's like someone who smokes who just can not understand what to do if he would quit smoke, as so much would change to the worse (no breaks all the time, because, what to do then? getting fat, because one eats more, etc). you know singletons are bad, yet you don't even try to just work and think without them. try it.

If you ever used a 3d app like 3d studiomax, or photoshop, you would have loved more than one mouse.

The fact that you can't even imagine the possibilities (pinch to zoom with something as accurate as a mouse? a dream. same for rotation and stuff, 3d modelling in general) just shows how far a singleton can restricts ones mind.

the example i gave in an older post was about rendering to multiple contexts in the early days of opengl to do rendertotexture style stuff. as opengl is essentially a huge singleton, i never could grasp myself around it, i was too used to that "statemachine that just does everything for me". and that's exactly what singletons evolve into: huge "everythings" that then make you go blind on possibilities you're missing.


the other example (i think in the 'are globals bad' topic) was the player singleton. a lot do that, imagining there's just one player. but even in a singleplayer, that's not true. you have enemies. imagine them being able to use the same physics, the same movements, the same weapons, the same cars and planes and stuff that you do? they are a player, just one with a different "controller" behind it.

once you move away from the player singleton, suddenly you can be anything in the game, so you could start to mind-control other characters, etc. or they could use your vehicle when you don't look for it. suddenly, the game evolves while you develop it into something much bigger.

singletons always block you at the most important part: where you're thinking. because while coding, that part is active: your brain. and if the code does not allow you to do stuff, you won't even imagine that stuff anymore.



and yes, touch and mouse are not the same. hence multitouch does not replace the power of multiple mice. i feel this the most when i'm producing music. to do it accurately, you can't use touch. you need a mouse. but more than one mouse would allow so many features we're used from multitouch, it would be great.

a singleton in mostly every os of today: the mouse.

if it wouldn't be, we could plug in more than one mouse and use more than one cursor (similar to multitouch) since years in every os. and heck yes, i would. sadly, at some point we got limited to only one device ever, as no one ever needs more than one cursor. and the whole os' got designed around it.

now that we can have multitouch, the os' are still not designed for it (at least win7). the result: i can not, for example, drag multiple windows independently around the desktop at the same time.


it's a simple example of potential that was there since years and never got exploited just because we where all fixed on "there can be only one".

I think the moral of the story is "making assumptions, especially implicit assumptions, is really stupid."

Or something to that effect.

I'm seeing assumptions from both sides, one that you will need more than one of these objects in future, and the other a simplifying assumption that chances are you won't.

What of the simplifying assumption that this class doesn't support multithreading? Or do I have to support mulitthreading for all classes because if I scale the system up I will likely need that one day? I just don't understand why everything has to be a black and white/all or nothing proposition.

Working with the cryengine SDK recently, and had a bit of a laugh seeing all the globals and #defines in there. But you know what, the world didn't end, I was able to get in there and update the code without a lot of hassle. Sure, it's no ideal, but answer me this - would cryengine be a better product had it been developed using software design best practices (under the same budget/time constraints). In my estimation, they wouldn't have a product today had they attempted to take this path.

If you work without globals and shared locals and stuff, you don't have to prepare for your classes to work with multithreading. they will just work. obviously, you have to write the multithreading stuff correctly, but you don't have to change anything in the class, or know any implementation details that you have to workaround then.

that's kinda the point: if you write code without globals and singletons and that crap, the code is more simple to write, and as a bonus, much simpler to use in future, nonpredicted scenarios.

just stop doing it and you'll notice it.

scene is a class that i create objects from, which are then the levels that one can play.

and yes, at load time, you put the filename (+relative path) as key into the map, and the actual loaded texture into the value, if it's not yet there. when ever you load a mesh, you check it's texture filenames against that map, add if not yet there, and replace the filename in the mesh with an iterator to the instance of the texture in the map (or a smart ptr, or what ever).

mostly one or twoliners, depends a bit on the language (i'm coding in c#, i guess you work in c++).

there will be a class game, which has a level currentlevel in it, on which update and draw will be called. a new level gets loaded by new Scene(filenameofscene); and that's it. it loads all it's textures into the map, all the meshes into their map, etc. and then processes the data in update, draws it in draw.

typically, scene can't even draw itself, but i just access all it's content to draw that in the drawing routine, but that's to each his own.



the biggest helper to stop creating global god-like variables: code what you use. not code something that might solve everything. code something that solves YOUR NEED. your level needs textures, so give it textures. it needs meshes, so give it meshes. done. that simplifies code massively. especially together with typical containers (vectors, maps). learn to use them instead of creating magical managers. much simpler in the end. much less of a mess.




btw, your 'fire' code example is perfect: if you have a global, only one player can shoot/trigger. multiplayer on the same machine? impossible.

but if you refactor it to have a class player, that stores it's own trigger variable, you suddenly can. a gun is then owned by that player, and shoots, if the player "is shooting".

the advantage: you can derive players: localxbox360controllerplayer, localkeyboardandmouseplayer, networkconnectedplayer, computeraiplayer, and they can all shoot individually, with the identical gun, the identical logic. they can even pick up your gun to use it, once they killed you.

singletons and globals always take away options you haven't even imagined. but believe me, at some point, you, or someone else will. then, rewriting everything will be the only solution.

in simple: it just shouldn't happen at that level. why can't a scene properly load it's textures (and all other data besides textures) without loading stuff multiple times? that's not part of a texture manager, it's just part of the scene to handle that.

scene {
std::<texturename, Texture> textures;
}

done.

there is your texturemanager, your complex global have to be thing that just does not need to.

when a level gets loaded, it loads all the data it has to, into it's own object. when the level gets unloaded, it frees it all.

with the singleton, all you do is, when a level gets loaded, it loads all the stuff into a global object. when the level gets unloaded, it frees it all from the global object (maybe).

it's the same. just, in one case, you actually handle it where the stuff belongs, instead of outsourcing it to something that artifically acts like a god to your application.


and no, there are NO issues with that. it's clean. it's simple. it just works.

you should be passionate and everything. but you have to know, and always consider, that you can be wrong on something. you're not perfect, sometimes someone else is right. and you have to accept that not everything you invented is pure gold and pure genius.

if you can't let go of ideas that failed/will fail, you're not good at your passion. because your main goal and passion is and should be making a good product. not a product with a feature you've invented, even if that feature is completely bollocks.

so put your passion into a higher level: the actual product (be it a game, a webpage you're designing, what ever).

an idea getting dismissed doesn't mean the idea itself was bad. it means it doesn't fit right now, right here. focus on the project, not your idea.

Happy birthday! It's great to have you around trough all those years.

c# here. because i CAN MANAGE MY OWN MEMORY, because i CAN write my own containers, because i can write my own file handlers for stuff like xml, because i can write my own database like interface and stuff. but i don't WANT to. oh, and strings, too. i want to get my stuff going. and my stuff is an end product, not a library or tool for other programmers.

oh, and, because i know that i'm not perfect, i know i would do errors with all of the above listed stuff. and those might be hard to trace. memory leaks are one of the biggest issues in the computer industry since years, source of bugs, crashes, hacks, viruses, etc. knowing that i will not be able to 100% prevent it, i prefer to have a compiler/language setup that i know it will.

I'm not sure as to the origins of this sentiment that discussing problems with the new site is somehow equivalent to whining or attacking the developers, but it's patently ridiculous. When you support a software product, you don't consider users submitting feedback and bug reports as personal attacks, do you? I know for me, user feedback is ALWAYS appreciated, even if we don't always end up making the change the user wanted. So much so, in fact, that both at work as well as in my hobbyist projects I continually reach out to users to cajole them into giving feedback. Trying to put a damper on that here seems absolutely mind boggling.

it's a typical behaviour that when something changes, people start to cry omg it's all bad. seen it often enough. feedback is appreciated, of course. but overreaction is not.

As for the rating system, it's not hard to look at the new system and determine logically what the outcome of its effects will be. You don't always have to run an experiment to know the outcome of a process. Trying to dump off the role previously filled by the rating system onto the moderators, who already have enough work to do, doesn't sound like a brilliant move to me. It's not really their job to try to run posts through the constantly fluctuating filter of community standards, and even if it were I don't think they could do it with any degree of success.

well, as said, i know it works very well in .. well, about any other forum. so yes, looking at the outcome means one thing: it should work very well here, too.

Where would they draw the line? Profanity? How about if I just call you a stupid moron? What if I followed you around and after every single one of your posts, I also posted a followup "I think everything he just said is wrong."? I bet that would get me an even higher rating, since a few people might find it funny to rate those posts up, and anyone who finds it annoying won't have any recourse but to bug the moderators to censor me when the actual content of my posts isn't breaking any rules.

I think everything he just said is wrong.


sorry, had to but that's about exactly my point: always this negativity, always this "that could go wrong in so many ways!!" how about trying and see if it does? so far, in other fories, it did not go wrong. why should this be different? are we such a bad community?