Re: Refactoring Patch

On Sun, 2003-08-10 at 14:50, Andreas Rottmann wrote:
> Ralf Engels <[email protected]> writes:
> 
> > Hey you, returning parameters via &ret is very bad. From the calling
> > side you can't see what's going on. * ret is much better in this case.
> >
> This is a controversial issue. I'd rather go for more decriptive
> function names (e.g. get_file_position() rather than
> tell()).

I agree with Andy here, more descriptive names are a better choice
than using the address-of operator for return values.   
Even Bjarne[1] mentions the problem i.e. when to use pointers
or references for arguments.  
His advice in order of preference:

1. Don't modify arguments, return a new value
2. use a pointer/reference but with descriptive name.

Well, I am not sure we would want to use copy-and-modify(1) 
to return new values all the time, but I do see the point
that functions that change the argument can be hard detect
on a cursory glance at the interface.

Personally I like references. Many languages
have call-by-reference in comparison to C's call-by-value only
usage. C programmers have always faked call-by-reference using
pointers for large read-only objects such as structs, even
when the interface would suggest that the argument could be
modified.

Coplien[2] goes into a lot of detail why
operators need references in order to provide
clean/efficient interfaces to classes such as "complex" numbers.
He briefly mentions that they are often used to
permit call-by-reference common in other languages.

The main problem is the split between
class like objects and built-in types in C++.

For class like objects, references always make sense:

1.  read-write types should  be "type&" as an argument
2.  read-only  types should be "const type& " as an argument

This stems from the fact that passing large objects on
the stack by value can be quite costly in terms of runtime
performance.

For builtin types the logic breaks down a little and
there is a little more flexability basically to remain
compatible with C.   The reason is simply that  it is
more efficient to pass an "int" or "float " by value
than by reference/pointer when it cannot be modified.
I think I would still prefer to use "const int&" and
have the compiler decide that it could use pass-by-value
parameter. 

So for built-in objects, best practice is:

o  r/w built-in types are passed by reference or pointer
o  r/o built-in types are passed call-by-value

Again, the problem mainly stems from the fact
that built-in types are not first class objects in C++,
but the closer you can make them act like first class objects,
the easier for everyone it is.

References can also help the compiler do some optimization.
Notice that references sometime work as write-once pointers
i.e. that object they point to will not change for the lifetime
of the reference.

int a;
int &b = a;  // any assignment of b will modify a.


All in all, I find working with references easier
to read, but that may be because I often work with java
and other reference friendly languages.

Soooo... after all that explanation I think the refactoring
patch can be applied, but in the future it would be better
to stick to reference arguments and decent commenting.
I was pleased to see some Doxygen style comments appearing
in the patch.. Documentation patches are always welcome.

[1] C++ programming language: Bjarne Stroustrup 3rd Edition (pp. 97,
146)
[2] Advanced C++, James Coplien (pp. 431)

-- 
email:[email protected] office:(805)893-4276 http://www.cs.ucsb.edu/~kris



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01