Messages

1

Open Feedback / Re: How is my code?

« on: January 11, 2011, 04:18:20 pm »

Hi!

Stroustrup says, that one must consider different levels of abstraction. You (SupSuper) said, you'd need to implement all of those other companion functions. This is not entirely true since those functions don't share the same level of abstraction.

accelerate() means, that the plane accelerates. How it does so, depends entirely on the plane and therefore on your implementation of that plane. For example, when accelerating, it might also increase fuel consumption as well.

accelerate() might call the private functions setSpeed() and setFuelConsumption()

move(position) and stop() could call accelerate() or brake() then

Another problem is code duplication. Let's say you really want to only change speed of your plane. Ok, no problem (yet). This would be:

plane.getSpeed();
- change speed here -
plane.setSpeed();

Three simple lines which might be copy & pasted everywhere they become necessary. But now you already choosed one implementation and this will constrain you in the future (and may cause some refactoring). What do you do, if you want to change speed slowly (interpolated)?

- You'd need to change those three lines everywhere in your code. Maybe it would become 5 lines now or even more.
- You might forget some locations
- You might later fix a bug in these 5 lines and forget some code locations
- Consider adding extra features like setting fuel consumption (another 3 lines to add everywhere)

Apart from that I think addSpeed() isn't a good idea (as Daiky pointed out already).

2

Open Feedback / Re: How is my code?

« on: January 06, 2011, 02:59:25 pm »

I know that it makes this become const and I know that the pointer itself gets const, but well, you both got my point anyway. I was rather speaking about the general aspect of constness of functions within a class and its true meaning¹, rather than about the syntactical correctness.

For example, I as a library user might see that a function is declared const. So as logical consequence I'm asserting that this function won't modify my object in any way. But if I am able to modify its private variables² due to the exposure of its private pointers (through a getter), my object may change its state and behave differently after that call, which can be fatal, not only in a multithreaded environment.

3

Open Feedback / Re: How is my code?

« on: January 05, 2011, 01:54:17 pm »

Use const on getter methods - It is a good idea to make getter methods const, this prevents member variables from being modified.  For example, if you had a method "Target* getTarget()", it would change to "Target* getTarget() const"

Isn't that a bit restricting? Like requiring all related variables to be const or never changing or something? Gawd knows I probably have some half-assed code buried in there somewhere that might break.

The const functions are more restrictive.  A const function requires that none of the class member variables are modified during the function. [...] Generally if you just have a simple getter method that is  returning a member variable, you can easily change the function to be const.

And you'd better return a const type as well. Because the caller may access and modify the returned "Target"-object which is a member of your class which... therefore may get modified.

So your "getTarget() const" statement wouldn't be so true anymore (you're lying: there's no guaranteed constness for your private data), since this function indirectly may modify a member due to providing non-const access to others.

It would be a way better option to leave the function non-const in order to indicate that, by calling the getter function, the class may indeed be modified.

See this example: https://codepad.org/spLX9mGG

Basically, by storing pointers, you get indirect ownership and therefore constness for your pointers, but not for the data pointed to. Generally, you wouldn't get away with this: https://codepad.org/OlCMvjdg

Btw, getters and setters aren't a good idea anyway.

There is a reason that we keep our variables private. We don't want anyone else to depend on them. We want the freedom to change their type or implementation on a whim or an impulse. Why, then, do so many programmers automatically add getters and setters to their objects, exposing their private fields as if they were public?

4

Offtopic / Re: Show your project

« on: August 21, 2010, 09:53:41 pm »

I'm glad it died. We need SupSuper for this project

5

Suggestions / Re: Input Options

« on: July 30, 2010, 03:45:57 pm »

There's also deselecting from aiming mode.