By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,418 Members | 1,082 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,418 IT Pros & Developers. It's quick & easy.

references

P: n/a
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
Jul 23 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
john townsley wrote:
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.

--
Regards,

Karsten
Jul 23 '05 #2

P: n/a
"john townsley" <jo**********@optusnet.com.au> wrote in message
news:42**********************@news.optusnet.com.au ...
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
Jul 23 '05 #3

P: n/a
john townsley wrote:
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.
Jul 23 '05 #4

P: n/a
David White wrote:
john townsley wrote:
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 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.

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).
Jul 23 '05 #5

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cu**********@nntp1.jpl.nasa.gov...
David White wrote:
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 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.


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
Jul 23 '05 #6

P: n/a

"David White" <no@email.provided> wrote in message
news:2V*****************@nasal.pacific.net.au...
"john townsley" <jo**********@optusnet.com.au> wrote in message
news:42**********************@news.optusnet.com.au ...
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


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!
Jul 23 '05 #7

P: n/a
"john townsley" <jo**********@optusnet.com.au> wrote in message
news:42**********************@news.optusnet.com.au ...
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

Jul 23 '05 #8

P: n/a
E. Robert Tisdale wrote:
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;
}
> g++ -Wall -ansi -pedantic -o main main.cc
> ./main

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

Jul 23 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.