why I don't use references

[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.

[Ioannis Vranos]

"Tom" <No****@NoSpam. com> wrote in message
news:Q2******** **********@news 20.bellglobal.c om...

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.
And that's what a reference is supposed to be.

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'.

A programmer should check the function signature. Else how can he know what
arguments it takes?


Is there a solution to this?

Yes always check the function argument types and return type.



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Victor Bazarov]

"Tom" <No****@NoSpam. com> wrote in...

The motivation for references seems clear: stop people from using nasty
pointers when all they really want is a reference to an object.
That's nonsense. If pointers were useless, they would have
been taken out of the language. If references were useless,
there would be no place for them, too.
But C++ references are so inadequate that I'm still using pointers for my
references to objects. [...]
Well, it's definitely not a good sign when one begins blaming
one's own inadequacies on the tools one has chosen to use...
Is there a solution to this?

A good C++ course, perhaps.

Victor

[David White]

Tom <No****@NoSpam. com> wrote in message
news:Q2******** **********@news 20.bellglobal.c om...

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?

Yes, you could simply not use references in such cases if you are
uncomfortable with them. Pointers have their uses and references have their
uses. Obviously, where you want the option of null or reseating, references
are not suitable. Where a function changes something via a function argument
there is, as you've explained, a good case for preferring a pointer. But
what about this case?

void f(const VeryLargeObject &obj);

Any reason to prefer a pointer here?

Also:
std::cout << "Result: " << result << std::endl;

How would this be done if a stream did not return a reference to itself from
its operator<<?

DW

[Victor Bazarov]

"David White" <[e-mail] ded> wrote...

[...]
std::cout << "Result: " << result << std::endl;

How would this be done if a stream did not return a reference to itself from its operator<<?

I bet you the OP will tell you that operator overloading
is inadequate anyway, and the statement above should look
like

std::cout.print ("Result: ").println(resu lt);

Victor

[E. Robert Tisdale]

Tom wrote:

The motivation for references seems clear:
to 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.

int a = 0;
int b = 0;
int* p = &b;

[Tom]

"David White" <[e-mail] ded> wrote in message news:R0******** ********@nasal. pacific.net.au. ..

Tom <No****@NoSpam. com> wrote in message
news:Q2******** **********@news 20.bellglobal.c om... .... Yes, you could simply not use references in such cases if you are
uncomfortable with them. Pointers have their uses and references have their
uses. Obviously, where you want the option of null or reseating, references
are not suitable. Where a function changes something via a function argument
there is, as you've explained, a good case for preferring a pointer. But
what about this case?

void f(const VeryLargeObject &obj);
Yes, I have no problem using references like this. I just don't tend to do it because, if I can only use references for a small % of my parameter passing needs, I feel it is better to always use pointers. More consistentency.

Thanks,
Tom.
Any reason to prefer a pointer here?

Also:
std::cout << "Result: " << result << std::endl;

How would this be done if a stream did not return a reference to itself from
its operator<<?

DW

[Graeme Cogger]

Tom wrote:

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'.

I think the idea that 'pointer args return values' is itself misleading
if people use 'const' arguments (which is a good thing). Consider the
following function prototypes:

1) void MyFunc( MyType &x );
2) void MyFunc( const MyType &x );
3) void MyFunc( MyType *x );
4) void MyFunc( const MyType *x );

Whether I pass 'Y' or '&Y' tells me nothing about whether the function
can modify 'Y'.

[Michiel Salters]

"Victor Bazarov" <v.********@att Abi.com> wrote in message news:<Qb1Ra.729 71$N7.8517@sccr nsc03>...

"David White" <[e-mail] ded> wrote...

[...]
std::cout << "Result: " << result << std::endl;

How would this be done if a stream did not return a reference to itself

from

its operator<<?

I bet you the OP will tell you that operator overloading
is inadequate anyway, and the statement above should look
like

std::cout.print ("Result: ").println(resu lt);

Victor

I guess he'll want

std::cout->print("Resul t: ")->println(result );

which is more confusing, as the arrows point the wrong way.
Using std::cin with this style would look nice, though.

Regards,
--
Michiel Salters

[Norbert Riedlin]

"Victor Bazarov" <v.********@att Abi.com> wrote in message news:<Qb1Ra.729 71$N7.8517@sccr nsc03>...

"David White" <[e-mail] ded> wrote...

[...]
std::cout << "Result: " << result << std::endl;

How would this be done if a stream did not return a reference to itself

from

its operator<<?

I bet you the OP will tell you that operator overloading
is inadequate anyway, and the statement above should look
like

std::cout.print ("Result: ").println(resu lt);

And then again, what would the return type of
std::cout.print (const char*)
be? Perhaps a reference...?

Norbert