Talk:Reference (C++)

From Wikipedia, the free encyclopedia

"In the C++ programming language, a reference is a simple reference datatype that is less powerful but safer than the pointer type inherited from C, which is a reference in the general sense but not in the sense used by C++." huh????

[edit] not true...

copied from the article:

"In many implementations, normal parameter-passing mechanisms often imply an expensive copy operation for large parameters. References qualified with const are a useful way of passing large objects between functions that avoids this overhead:

 void f_slow(BigObject x) { /* ... */ }  
 void f_fast(const BigObject& x) { /* ... */ }
 BigObject y;
 f_slow(y); // slow, copies y to parameter x
 f_fast(y); // fast, gives direct read-only access to y

If f_fast() actually requires its own copy of x that it can modify, it must create a copy explicitly. While the same technique could be applied using pointers, this would involve modifying every call site of the function to add cumbersome address-of (&) operators to the argument, and would be equally difficult to undo, if the object became smaller later on."

It is NOT correct that address-of ("&") operators need be used, at least for reasonably modern C/C++ compilers (less than 10 years old or so?) It's legal to omit the "&" as long as the declarations are correct.

For example:

 void f_AlwaysFast( BigObject *x ) // accepts a pointer to a modifiable BigObject.
   { /* ... */ }
 void f_MaybeFast( const BigObject *x ) // accepts a pointer to an immutable BigObject.
                                                    // must copy the object if needed.
   { /* ... */ }
 void f_AlwaysSlow( BigObject x ) // accepts a copy of a BigObject.
   { /* ... */ }
 ...
 BigObject y;
 f_AlwaysFast( &y );  //this is of course legal...and is identical to the following:
 f_AlwaysFast( y );   //this is also legal - it passes the address, not a copy of the object.
                      //...an assumption is made from the declarations of the function and the object.

So, the argument against pointers seems invalid. Not that it made much sense to me anyway...it implies that one is modifying existing code to use pointers instead of references, just for fun.

This brings up one of my main problems with C++. As if C didn't have enough ways to do the same thing, C++ introduces a bunch more, for no apparent gain. Granted, C++ provides some new things we can do...but still, the number of new ways to do the same old stuff is amazing. There's a lot more ways to do things that one must learn, and the risk of choosing the wrong way to do something goes up, not down. The risk of failing to correctly understand what some other programmer did goes up, not down. Complexity has been added, and for all its claims of being safer, anytime you add complexity you add risk. --Shyland 16:33, 24 November 2006 (UTC)

...p.p.s. A more valid objection to the use of pointers is the necessity of using "->" as well as "." operators, and always having to keep straight whether "x.member" or "x->member" is appropriate. But this problem, as well as the one in the article, seems somewhat picky compared to the necessity to write efficient code. --Shyland 16:45, 24 November 2006 (UTC)

Er, maybe you're right that this particular point of comparison is picky, but you're simply wrong that you can pass an object of type BigObject to a function expecting an object of type BigObject *. That doesn't work, and has never worked in C or C++. It's a type mismatch and there's no implicit taking of addresses. Deco 04:09, 26 November 2006 (UTC)