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]

Re: why I don't use references

"Tom" <NoSpam@NoSpam. com> wrote in message
news:Q20Ra.1911 $ym.492662@news 20.bellglobal.c om...[color=blue]
> 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.[/color]



And that's what a reference is supposed to be.



[color=blue]
> 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[/color]
code[color=blue]
> 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[/color]
that[color=blue]
> f changes 'b'.[/color]


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

[color=blue]
>
> Is there a solution to this?[/color]


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]

Re: why I don't use references

"Tom" <NoSpam@NoSpam. com> wrote in...[color=blue]
> The motivation for references seems clear: stop people from using nasty
> pointers when all they really want is a reference to an object.[/color]

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.
[color=blue]
> But C++ references are so inadequate that I'm still using pointers for my
> references to objects. [...][/color]

Well, it's definitely not a good sign when one begins blaming
one's own inadequacies on the tools one has chosen to use...
[color=blue]
> Is there a solution to this?[/color]

A good C++ course, perhaps.

Victor

[David White]

Re: why I don't use references

Tom <NoSpam@NoSpam. com> wrote in message
news:Q20Ra.1911 $ym.492662@news 20.bellglobal.c om...[color=blue]
> 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[/color]
code[color=blue]
> 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[/color]
that[color=blue]
> f changes 'b'.
>
> Is there a solution to this?[/color]

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]

Re: why I don't use references

"David White" <no@email.provi ded> wrote...[color=blue]
> [...]
> std::cout << "Result: " << result << std::endl;
>
> How would this be done if a stream did not return a reference to itself[/color]
from[color=blue]
> its operator<<?[/color]

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]

Re: why I don't use references

Tom wrote:
[color=blue]
> The motivation for references seems clear:
> to stop people from using nasty pointers
> when all they really want is a reference to an object.[/color]
[color=blue]
> 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:[/color]
[color=blue]
> 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.[/color]

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

[Tom]

Re: why I don't use references

"David White" <no@email.provi ded> wrote in message news:R01Ra.535$ sI.27182@nasal. pacific.net.au. ..[color=blue]
> Tom <NoSpam@NoSpam. com> wrote in message
> news:Q20Ra.1911 $ym.492662@news 20.bellglobal.c om...[/color]
....[color=blue]
> 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);[/color]

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.
[color=blue]
> 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[/color]

[Graeme Cogger]

Re: why I don't use references



Tom wrote:[color=blue]
>
> 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'.
>[/color]

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]

Re: why I don't use references

"Victor Bazarov" <v.Abazarov@att Abi.com> wrote in message news:<Qb1Ra.729 71$N7.8517@sccr nsc03>...[color=blue]
> "David White" <no@email.provi ded> wrote...[color=green]
> > [...]
> > std::cout << "Result: " << result << std::endl;
> >
> > How would this be done if a stream did not return a reference to itself[/color]
> from[color=green]
> > its operator<<?[/color]
>
> 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[/color]


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]

Re: why I don't use references

"Victor Bazarov" <v.Abazarov@att Abi.com> wrote in message news:<Qb1Ra.729 71$N7.8517@sccr nsc03>...[color=blue]
> "David White" <no@email.provi ded> wrote...[color=green]
> > [...]
> > std::cout << "Result: " << result << std::endl;
> >
> > How would this be done if a stream did not return a reference to itself[/color]
> from[color=green]
> > its operator<<?[/color]
>
> 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);[/color]

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

Norbert

[Victor Bazarov]

Re: why I don't use references

"Norbert Riedlin" <nr@netatec.d e> wrote...[color=blue]
> "Victor Bazarov" <v.Abazarov@att Abi.com> wrote in message[/color]
news:<Qb1Ra.729 71$N7.8517@sccr nsc03>...[color=blue][color=green]
> > "David White" <no@email.provi ded> wrote...[color=darkred]
> > > [...]
> > > std::cout << "Result: " << result << std::endl;
> > >
> > > How would this be done if a stream did not return a reference to[/color][/color][/color]
itself[color=blue][color=green]
> > from[color=darkred]
> > > its operator<<?[/color]
> >
> > 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);[/color]
>
> And then again, what would the return type of
> std::cout.print (const char*)
> be? Perhaps a reference...?[/color]

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

Victor

[puppet_sock@hotmail.com]

Re: why I don't use references

"E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message news:<3F149CCA. 5080308@jpl.nas a.gov>...
[snip][color=blue]
> There are very few cases
> where you actually *need* to modify an object *in-place*.[/color]

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]

Re: why I don't use references

"Cy Edmunds" <cedmunds@spaml ess.rochester.r r.com> wrote in message news:G74Ra.1903 6$G%5.3497@twis ter.nyroc.rr.co m...[color=blue]
> "Tom" <NoSpam@NoSpam. com> wrote in message
> news:Q20Ra.1911 $ym.492662@news 20.bellglobal.c om...[color=green]
> > ...
> > Is there a solution to this?[/color]
>
> 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.[/color]

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.
[color=blue]
> 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);[/color]

Yes, this is good form too. I like to see functions that look like this.

Thanks for your helpful answer,
Tom.
[color=blue]
> 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.
> [color=green]
> >
> > TIA, Tom.
> >
> >[/color]
>
> --
> Cy
> http://home.rochester.rr.com/cyhome/
>
> [/color]

[Tom]

Re: why I don't use references

"Simon G Best" <s.g.best@btope nworld.com> wrote in message news:3F14F138.9 090200@btopenwo rld.com...[color=blue]
> Tom wrote:[color=green]
> > The motivation for references seems clear: stop people from using nasty
> > pointers when all they really want is a reference to an object.[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
> > 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.[/color]
>
> 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).
> [color=green]
> > 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...[/color]
>
> Yes you can. It's in the prototype. However...
> [color=green]
> > 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'.[/color]
>
> 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.
> [color=green]
> > Is there a solution to this?
> >
> > TIA, Tom.[/color]
>
> 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.[/color]

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.
[color=blue]
>
> There are other uses for references, too, but I won't go into them now.
>
> Hope that helps clear things up!
>
> :-)
>
> Simon
> [/color]

[Default User]

Re: why I don't use references



Tom wrote:
[color=blue][color=green]
> > void f(const VeryLargeObject &obj);[/color]
>
> 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.[/color]


"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