Pointers vs. References

Pointers vs. References

Post by Victor Bazaro » Fri, 21 Jul 2000 04:00:00




> In developing some coding standards at my job a discussion
> came up over the relative merits of pointers versus references.
> A coworker has suggested we shun references and explicitly
> use pointers, the idea being that it's easier to know in
> the midst of a routine that changing a field of a pointer
> parameter will change it elsewhere, while a reference
> looks like a locally-scoped object or class memeber.

What it looks like is not a big deal, what the behave like
is much bigger deal, if you ask me.

Quote:

> Can anyone speak up for the reference and make a good
> case for using it instead of a pointer?

A reference always, and I mean ALWAYS, refers to a real object.
Pointers you have to check.  There can be a NULL pointer.

Quote:

> One notion that's occured to me is that, if one is to use
> pointers, passing references to pointers instead of simple
> pointers is actually safer.  If the object is deleted and
> the pointer-reference is set to NULL, it will be NULL everywhere.

A reference to a pointer?  Yewww...

Quote:

> Any other cases where a reference is better? Or theoretical
> defenses of its notation vs. that of pointers?

Actually, whenever you have to deal with dynamic memory, you have
to use pointers, there is no contest.  As to the notation...  It
is known that operator-> can be overloaded, and operator. (dot)
can't.  So, returning to your first paragraph, when I see
a->whatever, I can't really tell that 'a' *is* a pointer.  It does
act like one, that much I can say.

I suppose it's all a matter of preference.  If there was some
disbalance of one element of the language over the other, the
language wouldn't have the other, I guess.

Victor
--
Please remove capital A's from my address when replying by mail

 
 
 

Pointers vs. References

Post by ccorb.. » Sat, 22 Jul 2000 04:00:00


In developing some coding standards at my job a discussion
came up over the relative merits of pointers versus references.
A coworker has suggested we shun references and explicitly
use pointers, the idea being that it's easier to know in
the midst of a routine that changing a field of a pointer
parameter will change it elsewhere, while a reference
looks like a locally-scoped object or class memeber.

Can anyone speak up for the reference and make a good
case for using it instead of a pointer?

One notion that's occured to me is that, if one is to use
pointers, passing references to pointers instead of simple
pointers is actually safer.  If the object is deleted and
the pointer-reference is set to NULL, it will be NULL everywhere.

Any other cases where a reference is better? Or theoretical
defenses of its notation vs. that of pointers?

Thanks for discussion.
- Christopher

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

Pointers vs. References

Post by azer » Sat, 22 Jul 2000 04:00:00


I prefer pointers - This is because we have a huge project and compile time
is important. With pointers we can forward reference all our classes in our
header. It has improved our compile time by about 10 fold!

That said I dont have anything against references.

Sc



> > In developing some coding standards at my job a discussion
> > came up over the relative merits of pointers versus references.
> > A coworker has suggested we shun references and explicitly
> > use pointers, the idea being that it's easier to know in
> > the midst of a routine that changing a field of a pointer
> > parameter will change it elsewhere, while a reference
> > looks like a locally-scoped object or class memeber.

> What it looks like is not a big deal, what the behave like
> is much bigger deal, if you ask me.

> > Can anyone speak up for the reference and make a good
> > case for using it instead of a pointer?

> A reference always, and I mean ALWAYS, refers to a real object.
> Pointers you have to check.  There can be a NULL pointer.

> > One notion that's occured to me is that, if one is to use
> > pointers, passing references to pointers instead of simple
> > pointers is actually safer.  If the object is deleted and
> > the pointer-reference is set to NULL, it will be NULL everywhere.

> A reference to a pointer?  Yewww...

> > Any other cases where a reference is better? Or theoretical
> > defenses of its notation vs. that of pointers?

> Actually, whenever you have to deal with dynamic memory, you have
> to use pointers, there is no contest.  As to the notation...  It
> is known that operator-> can be overloaded, and operator. (dot)
> can't.  So, returning to your first paragraph, when I see
> a->whatever, I can't really tell that 'a' *is* a pointer.  It does
> act like one, that much I can say.

> I suppose it's all a matter of preference.  If there was some
> disbalance of one element of the language over the other, the
> language wouldn't have the other, I guess.

> Victor
> --
> Please remove capital A's from my address when replying by mail

 
 
 

Pointers vs. References

Post by Thore B. Karls » Sat, 22 Jul 2000 04:00:00




Quote:>> Can anyone speak up for the reference and make a good
>> case for using it instead of a pointer?
>A reference always, and I mean ALWAYS, refers to a real object.

No it doesn't.

void ohno(cls &obj)
{
   obj.method();

Quote:}

int main()
{
   cls *p = 0;
   ...
   ohno (*p);

Quote:}

--
A still tongue makes a happy life.
 
 
 

Pointers vs. References

Post by grzegor » Sat, 22 Jul 2000 04:00:00



> In developing some coding standards at my job a discussion
> came up over the relative merits of pointers versus references.
> A coworker has suggested we shun references and explicitly
> use pointers, the idea being that it's easier to know in
> the midst of a routine that changing a field of a pointer
> parameter will change it elsewhere, while a reference
> looks like a locally-scoped object or class memeber.

> Can anyone speak up for the reference and make a good
> case for using it instead of a pointer?

> One notion that's occured to me is that, if one is to use
> pointers, passing references to pointers instead of simple
> pointers is actually safer.  If the object is deleted and
> the pointer-reference is set to NULL, it will be NULL everywhere.

> Any other cases where a reference is better? Or theoretical
> defenses of its notation vs. that of pointers?

> Thanks for discussion.
> - Christopher

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Pointers versus references. Using one versus another may have
standardized meaning in your program.
For instance , using only pointers when variable is dynamically
allocated.
Using pointers for operations on polymorphic objects,
when dynamic type may be different from static type.
This way using pointers and references can make code more readable
and not otherwise.

--

 
 
 

Pointers vs. References

Post by Janusz Szpilewsk » Sat, 22 Jul 2000 04:00:00



> In developing some coding standards at my job a discussion
> came up over the relative merits of pointers versus references.
> A coworker has suggested we shun references and explicitly
> use pointers, the idea being that it's easier to know in
> the midst of a routine that changing a field of a pointer
> parameter will change it elsewhere, while a reference
> looks like a locally-scoped object or class memeber.

There are two major points of view to this problem found in the
literature:

1. Use a pointer instead of a non-const reference because it makes more
clear that you modify an external variable or that variable can be
modified in the function.

2. Use a reference wherever possible as it makes calling syntax and the
big picture of a function cleaner.

As it concerns the first point, even if pointers may signal to a
programmer that a variable can change it does not say it will. You can
always pass a pointer to a variable that is not going to change with the
calling syntax remaining the same. In the case of any incertitude
examining the called function signature and its pre/post conditions will
be necessary.
Information inside the function implementation whever you modify an
external variable is usually less important and even if, should be
rather based on function pre/post conditions as they are more complete.

There are also situations when calling a function you do not care, if
the variable is going to change or not, just because it is of an
abstract type provided by some external library, or you may wish to
obtain some syntax convenience.

I suppose that most of us got caught once in the past with the C scanf
function syntax while expecting that it could be analogical to more
often used printf. It was indeed, almost... Using a reference to the
passed variable could remove that problem completely.  

And such attitude refers the second point focusing on making the
function calling syntax more simple and clean hence readable and easier
to use. You do not have to keep in mind that a function needs the
address of a variable, remembering that a function requires a variable
of given type is much easier.
It remains up to the called function to be more "clever" than the code
that calls it and to use the given parameters properly.

It all appears as a tradoff to resolve - more information vs more
abstraction. I think that the second attitude is closer to OO and should
be prefered at least when it concerns definition of external interfaces.

Quote:> Can anyone speak up for the reference and make a good
> case for using it instead of a pointer?

It should be kept in mind that pointers and references are physically
very different. Pointers are legal variables while references only
aliases for other ones. When passing a parameter to a function,
references should be at least theoretically faster (no pointer
dereferencing is needed) and were conceived to deal more cleanly with
such situations where using a pointer can be considered as a workaround
for the same goal.

There are of course such situations when physically existing pointers
are really needed, but in many cases references may be a better
choice.  

Quote:> One notion that's occured to me is that, if one is to use
> pointers, passing references to pointers instead of simple
> pointers is actually safer.  If the object is deleted and
> the pointer-reference is set to NULL, it will be NULL everywhere.

But if assuming that every pointer will point everytime to the same
variable. It is quite a strong assumption to be a general rule. It is
also quite difficult to be obtained in large projects. Syntax mess
introduced that way may not be worth the results. I believe that more
traditional defining systematically function responsibility for deleting
an object should be more successful.

Greetings,
Janusz

 
 
 

Pointers vs. References

Post by Carlos Moren » Sat, 22 Jul 2000 04:00:00



> >A reference always, and I mean ALWAYS, refers to a real object.

> No it doesn't.

But you still haven't proved your statement:

Quote:> void ohno(cls &obj)
> {
>    obj.method();
> }

> int main()
> {
>    cls *p = 0;
>    ...
>    ohno (*p);
> }

This code is illegal.  Dereferencing a NULL pointer leads to
undefined behavior, period.  It's not the reference's fault --
it's the pointer's fault (more specifically, it's the illegal
operation's fault).  IOW, you can not use a fragment of
illegal code to prove something -- you'll have to try harder! :-)

Carlos
--

 
 
 

Pointers vs. References

Post by Carlos Moren » Sat, 22 Jul 2000 04:00:00



> There are two major points of view to this problem found in the
> literature:

> 1. Use a pointer instead of a non-const reference because it makes more
> clear that you modify an external variable or that variable can be
> modified in the function.

Where did you find this?  So according to them, the function std::swap
should not receive parameters by reference??  ...Horrifying, isn't it?

Quote:> aliases for other ones. When passing a parameter to a function,
> references should be at least theoretically faster (no pointer
> dereferencing is needed)

What?!  I don't think there is a compiler on this world that generates
different code for these two functions:

void swap (int * a, int * b)
{
    int tmp = *a; *a = *b; *b = tmp;

Quote:}

void swap (int & a, int & b)
{
    int tmp = a; a = b; b = tmp;

Quote:}

What do you mean there is no dereferencing in the second one??  Of
course there is the exact *physical* dereferencing process -- it's
just that semantically, there isn't;  but the reference in that
case (and in most cases where the reference is passed to a
different scope) would be internally implemented by the compiler
as a pointer!

Quote:> There are of course such situations when physically existing pointers
> are really needed, but in many cases references may be a better
> choice.

So, we do agree on the bottom line after all...  :-)

Scott Meyers put it nicely in his book:  "Use references when
you can and pointers when you must"

Carlos
--

 
 
 

Pointers vs. References

Post by Thore B. Karls » Sat, 22 Jul 2000 04:00:00




Quote:>> >A reference always, and I mean ALWAYS, refers to a real object.

>> No it doesn't.
>But you still haven't proved your statement:
>> void ohno(cls &obj)
>> {
>>    obj.method();
>> }

>> int main()
>> {
>>    cls *p = 0;
>>    ...
>>    ohno (*p);
>> }
>This code is illegal.  Dereferencing a NULL pointer leads to
>undefined behavior, period.  It's not the reference's fault --
>it's the pointer's fault (more specifically, it's the illegal
>operation's fault).  IOW, you can not use a fragment of
>illegal code to prove something -- you'll have to try harder! :-)

Of course it's illegal. :) But it's a mistake that could easily be made.
Sending a dereferenced pointer to a function that takes a reference is not
that uncommon, and it would be just as easy to pass an invalid dereferenced
null pointer as to send the invalid null pointer itself.

But I'm always very careful, so such nastiness is never seen in my code. :)

--
A still tongue makes a happy life.

 
 
 

Pointers vs. References

Post by Branimir Maksimovi » Sat, 22 Jul 2000 04:00:00



> In developing some coding standards at my job a discussion
> came up over the relative merits of pointers versus references.
> A coworker has suggested we shun references and explicitly
> use pointers, the idea being that it's easier to know in
> the midst of a routine that changing a field of a pointer
> parameter will change it elsewhere, while a reference
> looks like a locally-scoped object or class memeber.

It is just matter of taste, not real difference.
Except, of course, you cannot reinitialize reference,
which means that references can be faster then
pointers.

Quote:

> Can anyone speak up for the reference and make a good
> case for using it instead of a pointer?

I don't know, I came from C background where there
are no references but anyway there is no real difference,
except that when you use dynamic_cast and similar, casting to
reference implies use of exceptions, but casting
to pointer not.

Quote:

> One notion that's occured to me is that, if one is to use
> pointers, passing references to pointers instead of simple
> pointers is actually safer.

Nooooo. Don't use reference to integral (small data) which
can fit in processor register. In that case always pass by value.
If you have to change value of small data, better do it like
this:
int func(int i){return i+1;}
 i=func(i);
then
void func(int&i){++i;}
func(i);

  If the object is deleted and

Quote:> the pointer-reference is set to NULL, it will be NULL everywhere.

I think that it will be performance killer in this case.

Quote:

> Any other cases where a reference is better? Or theoretical
> defenses of its notation vs. that of pointers?

I can't speak about theory, but I would think twice before
dumping something that language offers.
Avoid both pointers and references as much you can,
use auto objects and local vars instead of dynamic allocated
objects whenever you can, if performance is most important.
Second, consts are faster then non consts, therefore
you can consider reference as "constant pointer".
That means compiler wouldn't consider reference
itself as a variable which can change value.

Quote:

> Thanks for discussion.
> - Christopher

Greetings, Bane.
 
 
 

Pointers vs. References

Post by Janusz Szpilewsk » Sat, 22 Jul 2000 04:00:00




> > 1. Use a pointer instead of a non-const reference because it makes more
> > clear that you modify an external variable or that variable can be
> > modified in the function.

> Where did you find this?  So according to them, the function std::swap
> should not receive parameters by reference??  ...Horrifying, isn't it?

It is more or less that what stated the original poster. Of course it is
a design principle and not a rule to be followed blindly. To give an
example, it is mentioned also somewhere in Bjarne Stroustrup's "C++ PL".

Quote:

> What do you mean there is no dereferencing in the second one??  Of
> course there is the exact *physical* dereferencing process -- it's
> just that semantically, there isn't;  but the reference in that
> case (and in most cases where the reference is passed to a
> different scope) would be internally implemented by the compiler
> as a pointer!

Many depends on used compiler and computer architecture so I wrote
"theoretically". According to the C++ standard reference may or may not
require storage, so it is legal if the direct address of a variable is
used in the place of reference so that does not require any
dereferencing.

But it is true that in many cases it is difficult to implement and
references are implemented like pointers. Nevertheless I suppose that no
storage references, for instance, should work fine with inlining, while
using pointers may introduce some extra variables.

Greetings,
Janusz

 
 
 

Pointers vs. References

Post by gbay.. » Sat, 22 Jul 2000 04:00:00




[snip]

Quote:> Scott Meyers put it nicely in his book:  "Use references when
> you can and pointers when you must"

When it comes to passing objects as parameters, Allen Holub
in _Enough Rope..._  makes it quite simple

1) pass a const& if the object will not be modified
2) pass a pointer if the object will be modified

The reason is readability - if you see "foo( bar )" you can expect
that bar isn't modified, if you see "foo( &bar )" you understand
that it might be. Following Scott's advice you'd write "foo( bar )"
in either case leaving the reader to either guess or spend time
investigating. When the function has multiple parameters the
advantage of Holub's approach is even clearer:

fee( fie, foe, &fum )

Quote:> Carlos
> --

Sent via Deja.com http://www.deja.com/
Before you buy.
 
 
 

Pointers vs. References

Post by Simon Rigde » Sat, 22 Jul 2000 04:00:00



>I prefer pointers - This is because we have a huge project and compile time
>is important. With pointers we can forward reference all our classes in our
>header. It has improved our compile time by about 10 fold!

>That said I dont have anything against references.

If you mean forward-declaring classes in headers rather than doing a
#include, you can do that when using references too. You can on my compiler
anyway!

Personally, if it is a straight choice between a reference and a pointer I
always choose a reference. But sometimes only a pointer will do.

 
 
 

Pointers vs. References

Post by Simon Rigde » Sat, 22 Jul 2000 04:00:00


Quote:

>Personally, if it is a straight choice between a reference and a pointer I
>always choose a reference. But sometimes only a pointer will do.

Sorry, hit post before I'd finished...

I prefer references as IMHO they are inherently safer. Unlike pointers, they
cannot be NULL and they must always be bound to a valid object on creation
(although that object may still die and leave the reference dangling).

However, it is exactly these two benefits that make references impractical
in certain situations.

 
 
 

Pointers vs. References

Post by Mark Wilde » Sat, 22 Jul 2000 04:00:00



Quote:> I prefer pointers - This is because we have a huge project and compile
time
> is important. With pointers we can forward reference all our classes in
our
> header. It has improved our compile time by about 10 fold!

You can do the same thing with references. You can forward declare any name
where the name's members or size aren't required. This means you can even do
this:

 class C;
 void foo(C);