T
Tom
The motivation for references seems clear: stop people from using nasty
pointers when all they really want is a reference to an object.
But C++ references are so inadequate that I'm still using pointers for my
references to objects. There are 3 reasons why I find them inadequate:
1 - Can't be null.
2 - Can't be reseated.
Now I'm sure there are good reasons for these first 2, but it's #3 that I
can't get over:
3 - Can't tell which parms are references...
If I write a fn sig as 'void f( int x, int* y )', then the client code is
'f( a, &b )', so it is clear to everyone what is going on.
BUT, if I write a fn sig as 'void f( int x, int& y )', then the client code
is 'f( a, b )', and the compiler won't tell the coder that he has
misunderstood the function, and someone reviewing the code won't notice that
f changes 'b'.
Is there a solution to this?
TIA, Tom.
pointers when all they really want is a reference to an object.
But C++ references are so inadequate that I'm still using pointers for my
references to objects. There are 3 reasons why I find them inadequate:
1 - Can't be null.
2 - Can't be reseated.
Now I'm sure there are good reasons for these first 2, but it's #3 that I
can't get over:
3 - Can't tell which parms are references...
If I write a fn sig as 'void f( int x, int* y )', then the client code is
'f( a, &b )', so it is clear to everyone what is going on.
BUT, if I write a fn sig as 'void f( int x, int& y )', then the client code
is 'f( a, b )', and the compiler won't tell the coder that he has
misunderstood the function, and someone reviewing the code won't notice that
f changes 'b'.
Is there a solution to this?
TIA, Tom.