Public Group

# Pointers and References: which one to use and when?

This topic is 5390 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Also Should I just use references whenever possible? ARe dynamic memories the only "exclusive" use of pointers (beside iterators)?

##### Share on other sites
The biggest difference between the two is that you cannot have null references in any well-defined program. So you should use pointers when you wish to have a refer to a nothing value, and use references when there should always be an object there to refer too.

##### Share on other sites
An exception to what Jingo writes is this: don't use non-const reference as a function parameter. A non-const reference parameter can be changed, although it appears as if it can't.

For example, in the following code it appears that bar is not changed ...
    int bar = 0;    foo( bar );    ...

... but it is changed:
    void foo( int & x )    {        x = x * 69069 + 1;    }
If you write foo like this ...
    void foo( int * x )    {        x = x * 69069 + 1;    }
... then it is obvious that bar can change:
    int bar = 0;    foo( &bar );    ...

##### Share on other sites
Quote:
 Original post by JingoThe biggest difference between the two is that you cannot have null references in any well-defined program.

Actually there is complete difference between the two everyone will just say that references == pointers but that is not always the case and how references are implementated underneath is compiler specific how-ever the standard does state you can safely assume for all purposes & intents:

a reference to an instance is the instance

for trivial cases the compiler can optimize such that a reference type will actually be the object/instance with-out any copy made what so ever (meaning no copy of address) where as a pointer is always a copy of address a pointer is a variable just like an integer nothing magical about them.

Don't use pointers for pass-by-reference schematics it only simulates pass-by-reference its really still pass-by-value but only a copy of address is made not the instance it refers if you need pass-by-reference schematics then actually use reference types, remember you can have a reference to pointer aswell.

You can also use reference types with polymorphic types and get polymorphic behaviour just the same as pointers.

Another thing that makes them different from pointers is what happens when using constant references with literals/temporary variables you can't do that with pointers.

Quote:
 Original post by JingoSo you should use pointers when you wish to have a refer to a nothing value, and use references when there should always be an object there to refer too.

Doesn't stop you from having some kind of special constant null/out-bounds value to achieve the same thing.

Quote:
 Original post by Si0nShould I just use references whenever possible?

Where it makes sense yes!!

Quote:
 Original post by Si0nARe dynamic memories the only "exclusive" use of pointers (beside iterators)?

Not really a reference-type in a function parameter could refer to statically/dynamically allocated memory but that is of no concern of the function.

I would say another use for pointers are mainly to build dynamic data structures,

Pointers give you more flexablitiy than reference types as they are variables they can be stored in containers (although technically there is an in-direct way of storing references), they can be manipulated etc.

[Edited by - snk_kid on October 13, 2004 5:53:54 PM]

##### Share on other sites
ok, but when u use pointers, the function is passed a 32bit address,
when using references, is the whole structure passed, or just a ptr?

##### Share on other sites
Quote:
 Original post by caesar4when using references, is the whole structure passed, or just a ptr?

The implemenation of reference types is compiler dependent but the standard states you can safely assume a reference to an instance is the instance.

For non-trivial cases mostly likely implemenated as a pointer then a copy of address is made, for trivial cases the compiler can optimize such that no copy is made what so ever (meaning copy of address), in all cases the instance itself is never copied.

##### Share on other sites
In addition, you also cannot have references to member functions.

Quote:
 its really still pass-by-value but only a copy of address is made not the instance it refers

You could of course pass the pointer by reference, and no copy would be made.

##### Share on other sites
Quote:
 Original post by JingoIn addition, you also cannot have references to member functions.

unfortunately not, but there is such a thing as a reference to a function e.g.

typedef void (&foo)(int);

foo is a type alias for a reference to a function that takes an int & has a return type void.

Quote:
 Original post by JingoYou could of course pass the pointer by reference, and no copy would be made.

There isn't much point unless you wont to modify the actual pointer passed in.

##### Share on other sites
Quote:
 Original post by JohnBoltonFor example, in the following code it appears that bar is not changed ...  int bar = 0; foo( bar ); ... ... but it is changed:  void foo( int & x ) { x = x * 69069 + 1; } If you write foo like this ...  void foo( int * x ) { x = x * 69069 + 1; } ... then it is obvious that bar can change:  int bar = 0; foo( &bar ); ...

I disagree with the practice being proposed.

Any experienced programmer will have seen "void foo(const int& x)" often enough that the absence of the word "const" will stand out.

Meanwhile, if you name things like "void wibbleTheX(int & x)" (or whatever is grammatically correct in context), then it is even more obvious that the method is expected to change the input, even without looking at the method signature; plus, clients are not forced to take addresses of things in cases where actual entities are more readily available than pointers thereto. (Go ahead and pass by pointer if you expect the calling code to have pointers "on-hand" most of the time.)

I think a better rule is that a method should only change its input argument if it is expected to do so; and if it is expected to do so, then it should in most cases (since that is the MO of the method). On the other hand, in C++ it may be better to limit this behaviour to object parameters (and leave primitives alone). (In Java, and presumably C# by extension, this problem more or less solves itself because of the pass-by-value-but-objects-are-really-pointers object model.)

##### Share on other sites
Quote:
 Original post by ZahlmanI disagree with the practice being proposed.Any experienced programmer will have seen "void foo(const int& x)" often enough that the absence of the word "const" will stand out.

The problem is not overlooking the lack of a "const" in the declaration. The problem is reading the code where the function is called.

When a programmer is trying to understand unfamiliar code, he can't look up every function's declaration and implementation. He has to make assumptions. When calling a function with a non-const reference parameter, the parameter appears to be pass-by-value when it is actually pass-by-reference. It would make code easier to understand if you didn't have to worry that case.

• 18
• 29
• 11
• 21
• 16