   performance of & and * when defining pointers
  Hi! , I would like to know which are the differences (in compiler optimization) between these two ways of passing pointers to a function:void myfunc(char* ptr)   {   *ptr=0;   }void myfunc(char& ptr)   {   ptr=0;   }both do the same, but I would like to know if the difference between them is just visual (cleaner code) or it really has an impact in the compiler.I ask because I have a lot of functions coded like the first sample, and I was thinking if it is worth to recode them as the second sample.thanks in advance. 
  No impact, at least none that you''d care about. But many programmers think that using references instead of pointers where possible produces much cleaner, clearer, and more easily maintainable code. If you agree with these people, then it is definitely worth recoding the functions.   "Sneftel is correct, if rather vulgar." --Flarelocke ;  Hey vicviper,You are not going to see any difference in performance between the two, as both functions will compile to the exact same set of processor instructions. Just use the syntax that makes the most sense for the particular function you are writing.gr,Jim.   Jim Offermanprogrammer/composer ;  References spare you from: having to check wether it is null. having to dereference everywhere.Performance is identical. Use references unless you need to change what they point to ('retarget' them).Additional hint - remember that you can create references within functions too. They can sometime spare you some typing without negatively affecting performance (and sometime even increasing it).overly trivial example:std::complex<double> a;...a = somevariable[i][j][k][l] + somevariable[i][j][k][l]*somevariable[i][j][k][l];   std::complex<double> a;...std::complex<double> &z = somevariable[i][j][k][l];a = z + z*z;   “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”    — Brian W. Kernighan (C programming language co-inventor) [edited by - Fruny on February 10, 2004 4:50:07 AM];  It would almost certainly be better if that function were implemented using copy in, copy out, which is a legitimate implementation of references (at least for primitives) and would almost certainly be preferable in this kind of a function.Of course, that function ought actually be inlined (being a single liner) or perhaps even eliminated (since setting pointers to null offers little utility, double deletion being a bug an'' all).;  Just changing them might be a lot of work. I would say it's worth doing, but it isn't as simple as you might imagine.The promises that the two functions make are quite different. The first says: 'I will dereference the pointer you pass. I will not check it. I will crash if you pass me a null pointer.' That might be fine for your purposes. Dereferencing a null pointer is bad news so if you're going to dereference a pointer without checking it your users should know that they have to pass you a valid pointer, or else.After thinking about that though you might say, okay I'll check it for null and if it is I'll do nothing, or throw an exception, or something else maybe.So now you have a function which promises to do one thing if you pass a valid pointer and something else (perhaps even throwing an exception) if the pointer is null. That might be fine for your purposes.Changing to the new style function and passing a reference instead of a pointer will mean you don't have to make any of these promises to users of the function. A reference can't be null (unless the person passing you the reference is incompetent - you can't protect yourself from incompetence or maliciousness). So as the reference is always going to be valid you don't need to say, 'this function will do possibly a number of different things, including throwing an exception'. So you've changed the promises the function needs to make - for the better in my opinion.Finally, the code which calls this new improved function is where the incompetent user comes in. If they have a pointer to something and now have to pass a reference instead, they have to dereference their pointer. It's up to them to check it for null. If they don't they'll either crash the app or pass you a null reference (which isn't something real... it's undefined beaviour but with some compilers you might actually get this far)So, as you go through changing pointers to be dereferenced you need to check them for null and take alternative action or know that they will never be null... the same guarantees as before.You will find you can sometimes push the use of pointers up and out of each function until you reach some interface which simply has to deal with pointers (two examples are a C api and the place that objects are created with new)Hope that gives you some breadth.   [edited by - petewood on February 10, 2004 6:30:04 AM]