reference doesn't work?

**asmileguo** · 08-09-2006

So a reference to an array is not legalized; of the codes I have seen, they must use other tricks. This is what I want to be clarified.

Originally Posted by Daved

>> Give me one good reason why references shouldn't be created for arrays. It makes no sense.

I don't know what you are talking about. Are you saying that a reference to an array should be legalized? Or are you saying that one should prefer a reference to a pointer to an array over a pointer to an array?

**Daved** · 08-09-2006

Please post that code. You keep mentioning code you've seen, but you haven't posted it, so we don't know what you are referring to.

**asmileguo** · 08-09-2006

If you don't mind, help me go over the codes at page number 23 (their number, right upper corner) of the following document:
http://www.numerical-recipes.com/cpppages/chap1sel.pdf

According to what you said, there should be no need to use reference for the vector, but they did...

**Mario F.** · 08-09-2006

Originally Posted by asmileguo

I found be writing as

Code:

int* &bar

is much clearer than

Code:

int  *&bar

I also notice in Stroustrop's book, he always write in the first way. Can all compilers handle that without confusion?

Compilers will deal with both forms nicely.

The choice on which one to use is up to you. I prefer the first form. All my variables are declared one per line (only rarely I don't). I find have the type clearly separated from the identifier much easier to read.

The second form however, helps when one wants to declare more than one variable on the same line.

Code:

int* foo, bar;

Is dangerous because many people can be skimming through the code and think bar is a pointer to int. When in fact it is an int.

Code:

int *foo, *bar;

is so-so. I personally don't like it. For easier reading variables should be declared one per line. Except perhaps on those cases where the names of the variables aren't too long, there aren't maybe more than two or three, they are strongly contextually related to each other, there are no pointers or references involved, and they have a short life span in terms of lines of code.

Code:

int* foo;
int* bar;

or 

int *foo;
int *bar;

Is probably the best way to do it. I like the first better. As for references, probably I picked from someone else, by I prefer to have them close to the identifier

**Mario F.** · 08-09-2006

Originally Posted by asmileguo

According to what you said, there should be no need to use reference for the vector, but they did...

Well... that's a bad example. A vector is not an array.

**asmileguo** · 08-09-2006

I'm sorry; obviously they define their own class that I don't understand much...

Originally Posted by Mario F.

Well... that's a bad example. A vector is not an array.

**anon** · 08-09-2006

When passing arguments to a function, you'd use pointers for arrays (because arrays are/decay to pointers).

When you want a function to modify the passed arguments, it's preferable to use references (no need for all the pointer dereferencing). Example swap(int& a, int& b)

When you don't want a copy of the arguments, which might be expensive when passing class objects to a function (if you pass a std::string to a function, it would allocate new memory and copy the string to it in addition to everything else(?)) Example: dostuff(std::string& s)

**Mario F.** · 08-09-2006

Daved actually has a very good point. I too wasn't seeing things from his angle. However, he is right.

It's not that you can't have a reference to a pointer (or an array for that matter). It's just that you will be adding a layer of complexity to your code.

Think about it. A pointer offers all the functionality a reference does. Does this mean one should only use pointers? Heck no! The former is still true "Use references when you can, pointers when you must.". However, why creating a reference to a pointer? Why complicate the code? Conceptually we look at references differently. We expect them to return many types, but not normally a pointer or an array.

As such we might surprise someone reading our code (or even ourselves when reading it later). It's definitely not a clear case of "you must NOT do it". But it is certainly a case of "you are probably better off not doing it"

**asmileguo** · 08-09-2006

I believe the "bad example" I use falls into your third category...

Originally Posted by anon

When passing arguments to a function, you'd use pointers for arrays (because arrays are/decay to pointers).

When you want a function to modify the passed arguments, it's preferable to use references (no need for all the pointer dereferencing). Example swap(int& a, int& b)

When you don't want a copy of the arguments, which might be expensive when passing class objects to a function (if you pass a std::string to a function, it would allocate new memory and copy the string to it in addition to everything else(?)) Example: dostuff(std::string& s)

**Daved** · 08-09-2006

>> I believe the "bad example" I use falls into your third category...
Yes, exactly.

**asmileguo** · 08-09-2006

Gee,
I learned so much today that I need to digest a bit. Thanks folks, especially Mario, Daved, siavoshkc...

**CornedBee** · 08-09-2006

Just to confuse matters, you CAN have a reference to a normal array. The syntax looks like this:

Code:

void func(int (&r)[10]);

int main()
{
  int ar1[5];
  int ar2[10];

  // Works fine
  func(ar2);

  // ERROR: Cannot convert int[5] to int (&)[10]
  func(ar1);
}

Usefulness is limited, because the size of the array must be fixed.