references

[john townsley]

are there any differences when using pointers or passing by reference when
using

1) basic variables
2)complex variable types like arrays,structures

it seems easier to simply pass by reference and simply forget about pointers
but thats seems to easy, there must still be a need for pointers

 

[Karsten Baumgarten]

are there any differences when using pointers or passing by reference when
using

1) basic variables
2)complex variable types like arrays,structures

it seems easier to simply pass by reference and simply forget about pointers
but thats seems to easy, there must still be a need for pointers

The difference is that a reference to an object basically is the object
itself, a pointer to an object is a pointer, not the object.

 

[David White]

are there any differences when using pointers or passing by reference when
using

1) basic variables
2)complex variable types like arrays,structures

it seems easier to simply pass by reference and simply forget about pointers
but thats seems to easy, there must still be a need for pointers

For the most obvious implementations of pointers and references, performance
is unlikely to be affected. However, a pointer can be null, but a reference
can't. Sometimes you might want to use a pointer so you can pass a null
pointer. Pointers can also be re-seated, but references can't. However,
pointers passed to functions usually aren't re-seated. Pointers can result
in uglier, more verbose code than references because a pointer needs to be
dereferenced, sometimes many times. You might also want to consider the call
to the function:
f(&anObject); // pointer
f(anObject); // reference
In the pointer case it's obvious from the call that an address is being
passed, and therefore that the function might change 'anObject' (if the
pointer is not to const). In the reference case you can't tell from the call
whether it's pass by value ('anObject' has to copied and cannot be changed)
or pass by reference (it is not copied and can be changed).

DW

 

[E. Robert Tisdale]

Are there any differences when using pointers
or passing by reference when using

1) basic variables or
2) complex variable types like arrays, structures

It seems easier to simply pass by reference and simply forget about pointers
but that seems too easy. There must still be a need for pointers.

Pass by reference and passing pointers are implemented the same way --
the compiler emits code to pass the address of the object.

There is never any reason to prefer passing a pointer
instead of passing by reference.

When you pass a complicated object:

struct X {
private:
// complicated representation
int I;
public:
// complicated functions
get(void) const;
};

by reference:

void f(const X& x) {
int i = x.get();
}

you can reference member functions with operator.
But, when you pass a pointer to a complicated object

void g(const X* p) {
const
X& x = *p;
int j = x.get();
int k = (*p).get();
int i = p->get();
}

you must use operator-> or
convert const pointer p to a const reference (*p or x)
so that you can use operator.

 

[E. Robert Tisdale]

For the most obvious implementations of pointers and references,
performance is unlikely to be affected.
However, a pointer can be null, but a reference can't.

cat main.cc

#include <iostream>

void f(const int& i) {
if (0 == &i)
std::cerr << "&i is null" << std::endl;
else
std::cerr << "&i is null" << std::endl;
}

int
main(int argc, char* argv[]) {
int* p = 0;
f(*p);
return 0;
}

g++ -Wall -ansi -pedantic -o main main.cc
./main

&i is null

Sometimes you might want to use a pointer so you can pass a null pointer.
Pointers can also be re-seated, but references can't.
However, pointers passed to functions usually aren't re-seated.
Pointers can result in uglier, more verbose code than references
because a pointer needs to be dereferenced, sometimes many times.
You might also want to consider the call to the function:

f(&anObject); // pointer
f(anObject); // reference

In the pointer case it's obvious from the call
that an address is being passed and, therefore, that
the function might change 'anObject'

class X {
// . . .
};

void f(const X&);
void g(const X*);

int main(int argc, char* argv[]) {
const
X x; // large object
// . . .
f(x);
g(&x);
return 0;
}

(if the pointer is not to const).
In the reference case, you can't tell from the call
whether it's pass by value ('anObject' has to copied and cannot be changed)
or pass by reference (it is not copied and can be changed).

In practice, this isn't a very useful observation.
Small objects, such as the built-in types,
are usually always passed by value.
Large opbjects, such as structures and arrays
are usually always passed by reference
(or by reference through a pointer).

 

[David White]

However, a pointer can be null, but a reference can't.

cat main.cc

#include <iostream>

void f(const int& i) {
if (0 == &i)
std::cerr << "&i is null" << std::endl;
else
std::cerr << "&i is null" << std::endl;
}

int
main(int argc, char* argv[]) {
int* p = 0;
f(*p);
return 0;
}

You still do not have a null reference, and in the above case you cannot
have: f(0);

You might also want to consider the call to the function:

f(&anObject); // pointer
f(anObject); // reference

In the pointer case it's obvious from the call
that an address is being passed and, therefore, that
the function might change 'anObject'

class X {
// . . .
};

void f(const X&);
void g(const X*);

int main(int argc, char* argv[]) {
const
X x; // large object
// . . .
f(x);
g(&x);
return 0;
}

(if the pointer is not to const).

And your point is?

In practice, this isn't a very useful observation.

Well, it's an observation. It's up to the individual to decide if it's a
useful one.

Small objects, such as the built-in types,
are usually always passed by value.
Large opbjects, such as structures and arrays
are usually always passed by reference
(or by reference through a pointer).

The fact remains that in the reference case you can't tell how the argument
is passed. Some might consider that a disadvantage. I did for a while, but
not any more. The OP might or might not, but it is something to consider.

DW

 

[john townsley]

For the most obvious implementations of pointers and references,
performance
is unlikely to be affected. However, a pointer can be null, but a
reference
can't. Sometimes you might want to use a pointer so you can pass a null
pointer. Pointers can also be re-seated, but references can't. However,
pointers passed to functions usually aren't re-seated. Pointers can result
in uglier, more verbose code than references because a pointer needs to be
dereferenced, sometimes many times. You might also want to consider the
call
to the function:
f(&anObject); // pointer
f(anObject); // reference
In the pointer case it's obvious from the call that an address is being
passed, and therefore that the function might change 'anObject' (if the
pointer is not to const). In the reference case you can't tell from the
call
whether it's pass by value ('anObject' has to copied and cannot be
changed)
or pass by reference (it is not copied and can be changed).

DW

why then would you use pointers if you can pass by reference , I still see a
lot of people using pointers so there must be a need.....so whats the
point!

 

[David White]

why then would you use pointers if you can pass by reference , I still see a
lot of people using pointers so there must be a need.....so whats the
point!

I gave arguments for and against using pointers. I can't think of any more.
If you believe after reading the responses that references are always
better, please explain why. As for why other people use pointers at times,
it could be for one of the reasons I gave, or for some other reason, or
because that's what they are used to from C.

DW

 

[Rolf Magnus]

However, a pointer can be null, but a reference can't.

cat main.cc

#include <iostream>

void f(const int& i) {
if (0 == &i)
std::cerr << "&i is null" << std::endl;
else
std::cerr << "&i is null" << std::endl;
}

int
main(int argc, char* argv[]) {
int* p = 0;
f(*p);

Undefined behavior. You are attempting to dereference a null pointer.

return 0;
}

&i is null

Even if you ignore the fact that it's undefined behavior (it probably works
on many implementations), this is very inelegant and irritating to anyone
reading the code. I strongly advice against doing that.