quote:
MSW - there is a potential function call involved with using a function-based modification, yes, but for most short functions the compiler will try to inline it, negating the difference. The keyword ''inline'' can be added to demonstrate that you know the function-call overhead might prove a bother, but in the end it''s still up to the compiler to decide if it can or cannot inline the function. Usually it does, for short functions like in the example.

[edit: for functions that have their bodies within the class specification (i.e. usually in the header file i.s.o. the CPP file), inline is implied, meaning the compiler will try hard to remove any function-call overhead and some temporary-object construction overhead]

Now that is what bothers me...this dependancey on the compiler to do such things...when there is a chance (no matter how small) that it won''t...I''m a bit of a control freak when it comes to programming, and don''t feel comfortable with the compiler "second guessing" my code...but hey, thats me...

quote:Original post by MSW
Now that is what bothers me...this dependancey on the compiler to do such things...when there is a chance (no matter how small) that it won''t...I''m a bit of a control freak when it comes to programming, and don''t feel comfortable with the compiler "second guessing" my code...but hey, thats me...

You are also relying on your compiler to produce good hex code. Do you go through the hex-code that your compiler ends up generating (I know people that do, to make sure it acts as they expect!). Inlining is not a black art. There are simply some things that cannot be efficiently or effectively inlined, such as recursive functions, and very large functions (they would give a considerable code bloat).

You think you''re a control freak, but there are thousands of things that you are implicitly relying on anyway. The best thing to do is to either trust the compiler, or really know your stuff and check exactly what the compiler is doing for certain cases, so that you can be sure.

For 95% of programmers out there, the compiler will do a better job at optimising than the programmer could hope to achieve, and in much less time. There are of course always things you NEED to know about the language and about how things get compiled to produce efficient code, but it''s no different from assembly language - branch prediction, MMX, SSE, cache optimisation, etc. are all things you''ll need to consider to produce similar code to your compiler!

So, don''t worry about it too much. If it really bothers you, and you REALLY need the performance, dig deeper.

While I realise that some topics come up over and over, and get tired sometimes, leave moderating to the moderators. Please leave off-topic posting and flaming to the lounge. If you have no desire to have the argument again, there are two options:
1. Point to the original argument thread (which I know is hard, with the search function disabled).
2. Just don't reply at all, letting other people handle the question.


(Better, Sabreman? I apologise for anything that might have been construed as a personal attack, and assure you it was not intentional.)

[edited by - MadKeithV on October 22, 2002 8:16:24 AM]

quote:
Do you go through the hex-code that your compiler ends up generating

LOL...I have done that

quote:
So, don''t worry about it too much. If it really bothers you, and you REALLY need the performance, dig deeper.

It''s pretty clear for this particular example that the class structure might not be the right way to go...at least given maybe a .00001% chance the compiler may miss the oppertunity to inline the function calls.

It''s also pretty clear that this example isn''t the best display of the power of OO programing, right?

Lets say you were working on a Pac Man clone...you have a maze filled with dots...the ghosts...pac man himself...the "power pills"...and the little "cherry" piece that roams the maze...

Now you could make each of the dots a object, as well as everything else...have them inherit from other base objects like 2Dpoint and so forth and so on...

but is that really the way OO is ment to be used?...sorry, this is tieing into another thread...maybe I do understand OO, but am confused on where it would prove most usefull...I meen you take this Pac Man clone...which I think wouldn''t bennefit a whole lot by OO abstraction (seems like overkill), but others might (even insist on it)...which makes the whole matter confuseing to me.

I''ve done some more deleting and editing, mostly for cleaning up the thread. Sabreman - check my post above, I''ve edited it. Is it clearer now?

maybe not Pac Man.
but imagine if you were dong an RTS game or an action 2D game.
it is IMHO to use OO for that task.
well first you are gonna have characters.
and those characters will do something.
so it would be better to use a class character than let''s say a C struct character.
from there you can inherit from the base class and make farmers, soldiers, potential road kill victims, or whatever!

for (please pray i don''t get flamed for use of class and being a beginner) example:

class character
{
public:
void attack (weapon, character);
int currentHealth (int health);
void selectWeapon (...);
private:
int health;
int weapon;
string weaponname;
int xposition, yposition;
}

in this makeshift class declaration (please SabreMan don''t flame me) what the character is "composed of" and what he can do with and to his composition is nicely put together here.
all characters will be able to use base class and can add necessary things if needed.

i hope this made some sense and helped even a little.

quote:Original post by RedGenie
Take this example for instance, would there be any performance difference?

If the pathfinding code is really so heavy, then the overhead of potentially non-inlined functions will be minimal. You might lose a very small amount of performance, but it will be negligible.