Excessive use of accessors?

[camelCase]

I didn't know how to best title this thread but it's just a silly question that popped up in my head.
I've been working on the framework for my game for a bit and recently re-wrote the entire Unit class (which is huge).

Anyways, within the class method definitions, should I use the accessors in them or just directly access it?
Like this:

void someClass::someMethod () {
    int i = getSomething();
    //Some stuff
    setSomethingAwful(getSomethingElse()*i+getSomethingElseEntirely());
}

Versus. this:

void someClass::someMethod () {
    int i = something;
    //Some stuff
    somethingAwful = somethingElse * i + somethingElseEntirely;
}

Is one faster than the other?
(I would think that the one filled with function calls is slower, right?)

 

[Vestras]

setSomethingAwful is better. The whole more function calls being slow is utter bullshit. It is completely unnoticeable and I doubt it'll be your actual problem if our application performs bad.

 

[camelCase]

Thanks, Vestras =)

 

[SerraAvenger]

The whole more function calls being slow is utter bullshit. It is completely unnoticeable and I doubt it'll be your actual problem if our application performs bad.

True

setSomethingAwful is better.

Don't overengineer unless you have to. There are cases where using abstractions for everything is a good idea. Sometimes it's just more work, fuglifies your code, but doesn't add anything. If you're using a good editor it is no problem to add an abstraction later.
Don't misread this: As long as you're accessing from the outside, use accessors. If you're working from inside, do if necessary.
In the case of doubt, use abstractions. Highly exaggerated, you have to find the balance between "getting things done" and "getting things right".

 

[Sgqvur]

It seams to me that getters/setters are being replaced in favor of properties which combine the
more readable syntax of a direct accessing of attributes/fields/data member/... and the data validation/update of
setters/getters.
So in my opinion you should use properties, and only in special cases (the only special case I know about is
the representation of a vector with 3 reals/floats =), using setters and getters with vectors will probably slow things a lot
and bloat a lot of things) using direct access (yeah this means no set/get methods oh well...=))

If you are using the Microsoft C++ compiler it seams it has additional features (see the wiki page for property) added to the language like properties.
(but that probably means your code will become less portable if you actually care)

 

[Vestras]

True

Don't overengineer unless you have to. There are cases where using abstractions for everything is a good idea. Sometimes it's just more work, fuglifies your code, but doesn't add anything. If you're using a good editor it is no problem to add an abstraction later.
Don't misread this: As long as you're accessing from the outside, use accessors. If you're working from inside, do if necessary.
In the case of doubt, use abstractions. Highly exaggerated, you have to find the balance between "getting things done" and "getting things right".

Yes, I agree. In the inside, use private members. From the outside, use accessors.

It seams to me that getters/setters are being replaced in favor of properties which combine the
more readable syntax of a direct accessing of attributes/fields/data member/... and the data validation/update of
setters/getters.
So in my opinion you should use properties, and only in special cases (the only special case I know about is
the representation of a vector with 3 reals/floats =), using setters and getters with vectors will probably slow things a lot
and bloat a lot of things) using direct access (yeah this means no set/get methods oh well...=))

If you are using the Microsoft C++ compiler it seams it has additional features (see the wiki page for property) added to the language like properties.
(but that probably means your code will become less portable if you actually care)

VC++ is Windows only, and honestly I think that property syntax is pretty damn ugly.

 

[s3rius]

getters are really only useful to be able to make more of your data private and to put restraints on them (e.g. post-conditions).

The compiler optimizes away all those function calls, however.

So in the end it basically is a question of what you're more comfortable with.

 

[camelCase]

Is there, like, a limit to what the compiler will and will not optimize for accessors and mutators?
IIRC, inline functions don't become inline if there's a loop or some other stuff.
Just a little curious.

But I think I might just stick to using the getters and setters so it's easier to modify parts of the code =x
(I'm so lazy, ugh)

 

[s3rius]

Yes, there are limits, but there aren't easy rules you can follow.
Loops will be inlined less often, because they lead to a lot of assembler code.

Basically the compiler checks if it's worth it by comparing how much assembler code it'd have to create when it inlines a function, compared to how much performance gain you'd get from inlining (no register swtiches, no address jumps).

One-lines will very often be inlined unless you do a lot of computation within it.. something like this maybe:

int blah(int x, data p){ //Does completely stupid things
    return GetRandomNumber(0, GetAverage(GetValueArrayFromData(p, GetArraySize(p)*size(x))));
}

In these cases it might not be worth inlining every instance of blah.

Simple getters/setters will always be inlined.

Nice to note: Virtual functions - even accessors - won't ever be inlined.

 

[camelCase]

Ahh..
Thanks