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******************@news20.bellglobal.com...

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******************@news20.bellglobal.com...

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]> 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(result);

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]> wrote in message news:R0****************@nasal.pacific.net.au...

Tom <No****@NoSpam.com> wrote in message
news:Q2******************@news20.bellglobal.com... .... 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.********@attAbi.com> wrote in message news:<Qb1Ra.72971$N7.8517@sccrnsc03>...

"David White" <[e-mail]> 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(result);

Victor

I guess he'll want

std::cout->print("Result: ")->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.********@attAbi.com> wrote in message news:<Qb1Ra.72971$N7.8517@sccrnsc03>...

"David White" <[e-mail]> 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(result);

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

Norbert

[Victor Bazarov]

"Norbert Riedlin" <[e-mail]> wrote...

"Victor Bazarov" <v.********@attAbi.com> wrote in message

news:<Qb1Ra.72971$N7.8517@sccrnsc03>...

"David White" <[e-mail]> 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(result);

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

It could be a wrapper object that stores a pointer in it.

Victor

[puppet_sock]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<3F**************@jpl.nasa.gov>...
[snip]

There are very few cases
where you actually *need* to modify an object *in-place*.

And when you do, it's likely you can write things quite sensibly
by using a member function of the object that needs to be modified.
Socks

[Tom]

"Cy Edmunds" <ce******@spamless.rochester.rr.com> wrote in message news:G7******************@twister.nyroc.rr.com...

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

...
Is there a solution to this?
The "solution" is to use the features of the language wisely. Although it is
true that the actual function signature can always be consulted, making the
calling sequence as clear as possible can't hurt. For instance, in:

z = f(x, &y);

z is obviously an output. x appears to be an input and y a secondary output,
but if the prototype reads:

int f(int &x, const int *y);

we see that appearances can be deceiving. For this reason, I prefer const
references and non-const pointers in argument lists. This still leaves some
ambiguities but at least isn't blatantly misleading.

Yes, this seems like good practise.

I do almost the same thing: I stick to const pointers and non-const pointers. So the only difference is that I have to check for zero on the first param (and you don't), but often I want this as a signalling mechanism. And being able to cover most parameter passing situations with only 2 forms (const* and non-const *) that are closely related and backward (to C) compatible is a good thing.
The difference between
a const reference and a simple formal argument has to do with whether a copy
is made or not. With large objects that can matter from an efficiency point
of view but from the point of view of the calling sequence the distinction
can often be ignored.

Const references come up a lot. For instance just about every time I have a
string as input to a function I use a const std::string &. If I have an
actual std::string it works efficiently but also matches a string literal
"like this" because it has a converting constructor.

For the output of a function it is hard to beat a return result for clarity.
For instance we use

double sqrt(double);
Yes, this is good form too. I like to see functions that look like this.

Thanks for your helpful answer,
Tom.
rather than

void sqrt(double*); // or even worse: void sqrt(double&);

but for some reason this excellent example isn't followed as much as I would
like and return results seem to be disappearing from a lot of the code I
see. I think this is a Bad Thing.

TIA, Tom.

--
Cy
http://home.rochester.rr.com/cyhome/

[Tom]

"Simon G Best" <s.******@btopenworld.com> wrote in message news:3F**************@btopenworld.com...

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.
That may be part of the thinking behind them, but I wouldn't put it that
harshly. It's more so that people don't have to use pointers as a way
to get the effect of passing by reference.

Yes, you're right.

But I guess I was wishing that they had introduced a feature that allowed us to clearly differentiate between the use of references to objects (in the sense that this is used in most other higher-level languages) and C-style pointers. This would then have allowed Tools to do more with those references.

For example, if they had made non-const references re-seatable then one could still declare a 'T & const' - a const reference that is - when you wanted a reference that couldn't be reseated.

But as references are now, they mostly duplicate existing functionality, without really adding to much.

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.

They're not pointers, so they aren't like pointers. They're references.
They fill a different role (so that pointers don't need to fill it).

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

Yes you can. It's in the prototype. However...

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

That's why it's not a good idea to pass variables by nonconst reference
unless it really makes sense to do so. However, the fact that there are
ways to make bad use of a feature does not itself mean that that feature
is itself bad (bad workers and tools?).

Const reference arguments are very useful for indicating to the compiler
that the objects being passed are not being passed by value. This may
be (and often is) because the objects are large, and needless copying is
a waste of execution time and memory. (Const reference arguments can
still be temporaries, though, as if being passed by value, as implicit
type conversions are permitted when the argument is a const reference.)

If, instead, you were to use pointers (perhaps const pointers) for that,
you'd be changing the interface to the function. It's not good practice
to change interfaces purely on efficiency grounds, unless it really is
necessary. Const references mean that it really isn't necessary, as
they don't affect the vast majority of actual uses of the interface.

Is there a solution to this?

TIA, Tom.

A solution to what?

Here's what I suggest:-

* Use const references for big arguments.

* Use member functions instead of ordinary functions when arguments
themselves need to be modified.

* Use nonconst pointers when member functions are unsuitable.

Yes, I agree. What you have suggested are good guidelines. And they fulfill my requirement of providing meaning info in the text of the calling function.

Thanks,
Tom.

There are other uses for references, too, but I won't go into them now.

Hope that helps clear things up!

:-)

Simon

[Default User]

Tom wrote:

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.

"A foolish consistency is the hobgoblin of little minds."
- Ralph Waldo Emerson
Use the tool that is correct for the job. Use pointers when pointers are
appropriate, use references when they are the right thing. This should
provide very little trouble for any programmer past the newbie stage.

It's senseless to want references work exactly like pointers, if they
did they would at best be syntactic sugar.


Brian Rodenborn

[E. Robert Tisdale]

Cy Edmunds wrote:

References are less "powerful" than pointers
because they can't do these things (be NULL or reseated).
C++ has lots of low power features such as new-style casts, private
and protected, declarations, and many others. This is a Good Thing.
I make it a point to use the least powerful language feature
that can do the job so I don't hurt myself with it.
In real life I don't use a chainsaw to trim my nails, either. :)
Which boils down to,
"Don't use pointer unless you *need* a reference that can be reseated."
Although it is true that
the actual function signature can always be consulted,
making the calling sequence as clear as possible can't hurt.
For instance, in:

z = f(x, &y);

z is obviously an output. x appears to be an input and y a secondary output,
but if the prototype reads:

int f(int &x, const int *y);

we see that appearances can be deceiving. For this reason,
I prefer const references and non-const pointers in argument lists.

Better yet, avoid any output through the argument list:

std::pair<int, int> f(int, int);

std::pair<int, int> z = f(x, y);
x = z.first();
y = z.second();

[ghl]

"Cy Edmunds" <ce******@spamless.rochester.rr.com> wrote in message
news:dA*******************@twister.nyroc.rr.com...

"ghl" <gl*******@comcast.net> wrote in message
news:3X********************@comcast.com...

General response:
Name the parameter variable in the called function the same as the

variable

in the caller and prepend an 'A' (for alias).
For z = f(x, &y);
declare
int z(whatever, Ay)

What is this? It looks like a function prototype or declaration but the
types of the formal parameters are left out. If they were put back in, you
would have something like:

Oops.
z = f(x, y);
and
int z(int whatever, int &Ay)
Is this better? (Forgive me for the first post -- and maybe this one too!)
--
Gary

[Cy Edmunds]

<snip>

Oops.
z = f(x, y);
and
int z(int whatever, int &Ay)
Is this better? (Forgive me for the first post -- and maybe this one too!)
--
Gary

OK, that makes more sense. But the A prefix doesn't tell me anything I can't
see from the declaration anyway. It might be of some use when I encounter it
in the function body though.

--
Cy
http://home.rochester.rr.com/cyhome/