Regarding the efficiency of member functions

[Etheran]

Use good coding practice until you get your project done and THEN worry about optimization.  A fully functional project > an optimized partially functional project by far.

[Telos]

Etheran - I am not sure that I agree with you.  If a large project is not designed with oprimization in mind from the beginning the code may not be designed in a fashion that will allow it to be improved without much more significant effort.  A working project is nice but having to backtrack and find memory leaks and other bits and pieces that can be modified to run just a bit faster is bad compared to keeping speed and [possibly] memory in mind when designing your software.

[Kp]

Hmm...this brings an interesting thing to mind. I seem to recall that the compiler will ignore the inline specifier if the function is too large. This being the case, why would you not declare every function as inline and just leave it to the compiler to sort things out?

Most compilers have an option to let the compiler choose any functions it wants to be inline.  This would be a better idea.

Based on how gcc performs when given permission to do this, I recommend declaring as static any functions that 1) are not called across files and 2) you expect the compiler might try to inline.  At least with gcc, it will completely skip emitting the function freestanding if all instances are successfully inlined (note that non-static functions might be linked from outside the file, so it can't be certain that those are all inlined - but static functions it knows everything about their linkage).

[Banana fanna fo fanna]

Get it working first, optimize later, BUT think ahead before you start.

You don't want to sweat optimization for a long time, but make sure you design with a little forethought.

[Arta]

You absolutely have to optimise as you go along. There is a place for optimisation after a project is complete - analysing your application for hotspots and concentrating on them, which allows you to identify regularly called or repetative code which may not be obvious during development - but not optimising as you go along just leaves you with much more work later.

It would be rather like cooking a meal with no seasoning, herbs, or flavourings (like stock or soy sauce). You could add them at the end, but if you add them as you go along, they influence the other flavours during cooking and you end up with a nicer meal

In other words, why write crap code and then fix it later? Isn't it easier just to write good code to start with?

[Adron]

If it's easier to write good code from the start, do it. If you have to spend time thinking about how to make it faster, don't do it until you see that you need to make it faster.

edit:
It's like spending three hours counting up the grains of salt when cooking your potatoes, and then when you're finally done, the meat is cold.

Instead of just throwing in a spoonful, getting it finished in time, and trusting that if there would be a few grains too few, the gravy will cover it anyway.