why I don't use references

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

Ioannis Vranos

Tom said:
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
 
V

Victor Bazarov

Tom said:
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
 
D

David White

Tom said:
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
 
E

E. Robert Tisdale

Tom said:
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;
 
V

Victor Bazarov

David White said:
[...]
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
 
T

Tom

David White said:
....
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.
 
G

Graeme Cogger

Tom said:
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'.
 
M

Michiel Salters

Victor Bazarov said:
David White said:
[...]
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,
 
N

Norbert Riedlin

Victor Bazarov said:
David White said:
[...]
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
 
V

Victor Bazarov

Norbert Riedlin said:
"Victor Bazarov" <[email protected]> wrote in message
David White said:
[...]
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
 
P

puppet_sock

E. Robert Tisdale said:
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
 
T

Tom

Cy Edmunds said:
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.
 
T

Tom

Simon G Best said:
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.
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).


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


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.


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

Default User

Tom said:
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

E. Robert Tisdale

Cy said:
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();
 
G

ghl

Cy Edmunds said:
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!)
 
C

Cy Edmunds

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!)

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top