Ok everyone, I don''t know every detail of every issue here, but here are some very important (and accurate) ones.

1. as Kylotan said - the intrinsic ''this'' pointer for member functions is NOT any different than the equivilent function in C. If you did not need a ''this'' pointer, you should not have made the function a member function (it should either be a global or class function).

2. as said somewhere - a reference parameter IS just a pointer which uses non-pointer syntax inside the function. So if it is not efficient enough to pass a pointer, don''t use a reference either. The main reason to use references instead of pointers is that behavior of the const specifier is much more intuitive, and you are intrensically stating that the parameter must be a valid object, whereas a pointer might be NULL. CAREFUL though, because the compiler DOES NOT prevent a caller from accidentally calling a reference parameter like this:

MyFunc(*objPtr);

and if objPtr is NULL, the functino will get called, but you will get an unknown exception when you try to use the object in MyFunc. Ugly huh!

3. It is almost always more efficient to pass built in types WITHOUT using pointers or references (but if they need to be changes they of course MUST use pointers/references), and it is almost always more efficient to pass classes / structs as pointers. This of course doesn''t take into account your design or intentions. Just because it''s FASTER to pass a pointer to an object into a function, doesn''t necessarily mean it''s BETTER. For one, if you are trying to develop bug free code, you can''t be SURE that a function you wrote six months ago doesn''t MODIFY the object you pass it. And then, six months from now, your not sure that a function it calls, wont change, and start modifying your object. Things get tricky to debug when you start passing pointers around where you don''t need to.

Stupid Me, 32bit not 16bit. Well, what about Arrays, wouldnt that be a great use of pointers?

quote:Original post by Xai

For one, if you are trying to develop bug free code, you can''t be SURE that a function you wrote six months ago doesn''t MODIFY the object you pass it. And then, six months from now, your not sure that a function it calls, wont change, and start modifying your object. Things get tricky to debug when you start passing pointers around where you don''t need to.

As an aside, this kind of thing is a good reason to get into the habit of enforcing ''const-correctness'' in your code.

An array name without the [] is a pointer to the first element of that array

quote:Original post by adammil
it''s actually impossible to pass an array on the stack

Actually several languages have features that let you pass arrays of arbitrary size on the stack. In this case the arrays are pushed on the stack after the activation record and a pointer to the array is placed in the activiation record as a standard parameter.

quote:Original post by random

func(struct *i) is better than func(int a, const int b)

No, because you''d lose the ''const'' on b. Consts are there to help you.

quote:
func(struct *i) is functionally equivalent to func(struct &i)
Class::func(int a) is functionally equivalent to func(Class *obj, int a)

Yes, but in both cases there are stylistic choices to be made based upon what you are trying to achieve.

quote:Does the same rules apply to return variables? In effect, should I only return a value when I absolutely have to? For example, a function that asks for a width must return (or be inline''d), but a function that blits doesn''t have to.

Umm, are you saying you''ve never written a function that doesn''t return a value before? Like:

void DoSomething(){    return;} 

Just use the void type. Don''t return anything if you don''t need to!

quote:Original post by null_pointer

Kylotan: Have you ever counted the number of times const is needed in a good class? 30, 40, 50?

Nah, more like 10 or so, since I keep my classes fairly small

But anyone here who doesn''t understand ''const-correctness'' should look into it. Any language feature which catches the dreaded ''a = b'' typed mistakenly instead of ''a == b'' is good in my book