Re: [Plib-devel] C++ Philosophy Question

[<Va...@t-...>]

Steve Baker wrote:
> 
> The thing I *really* dislike about ref parameters is that it's
> possible to see this in the header for a library somewhere:
> 
>    void some_funtion ( int x ) ;
> 
> ...you go and write code to use 'some_function' *knowing* for
> sure that:
> 
>    x = 6 ;
>    some_function ( x ) ;
> 
> *CANNOT* change the value of 'x'.

But you should have written then

  void some_function ( const int x );

instead. This showes the programmer that the function won't change x in
any circumstances. And when you've got a const you are also able to use
a ref as it won't change the variable - the compiler guarantees it. But
when you use a pointer there's no guarantee that the function won't
change the value - even if it's using the pointer only for the reason
that the parameter is too big to be copied efficiently. E.g.:

class foo
{
private:
  long big_array[10000];

public:
  /* ... */
};

void my_func1 ( foo x );	//can't change x. X will be copied
				//which is extremly unefficient.

void my_func2 ( foo& x );	//can change x, x won't be copied
				//=> fast but dangerous

void my_func3 ( foo* x );	//can change x, x won't be copied
				//=> fast but dangerous

void my_func4 ( const foo& x );	//can't change x, x won't be copied
				//=> fast and secure
> 
> What's nasty about 'ref' arguments is that some subsequent
> version of that library can change the parameter of
> 'some_function' to be 'ref' and then change the value of x
> inside the function without the author of the application
> code being aware that the libraries' policy has changed.
> The old call to some_function still compiles!  Eeeekkkkk!
> 
> Also, I like to be able to look at some complex code
> that uses 'some_function' and *know* that the parameter
> isn't altered by the the function just by looking at the
> call.  I don't even have to go off and read the manual
> for 'some_function' in order to know that.
> 
> The nice thing about good old fashioned C-style pointers
> is that when you see:
> 
>    x = 6 ;
>    some_function ( & x ) ;
> 
> ...that '&' shouts loudly to you to bear in mind that x may
> well have been changed by the call.  If you don't see an '&'
> then you don't need to know much about some_function in order
> to see that it doesn't change 'x'.
> 
> That makes code MUCH more readable.
> 
> I think 'ref' is *EVIL* because its syntax doesn't make it
> obvious.

IMHO you should use refs only in combination with const to increase the
speed and decrease the required memory. If you want to modify an object
you should use pointers. That the best of the two worlds - IMHO.

> > Anyway, that's it for religion, time to write some code.
> 
> Indeed.

That's programming style always. But this discussion makes at least
sense at it's about the code. It gets much more religious if people
start to discuss diferent styles of comments. 

<hiding mode=";-)">
To open the discussion: AFAIK does Steve hate the '//' comments...
</hiding>

CU,
Christian