M
man
can any one please tell me what is the diff between pointer and
reference.....and which one is better to use ....and why???????
reference.....and which one is better to use ....and why???????
N
Neelesh Bodas
O
Oliver Block
Hi,
a reference is like an alias. A different name for the same thing (i.e.
object or function). A Pointer points to the physical address of a
variable/object.
bye,
Oliver
a reference is like an alias. A different name for the same thing (i.e.
object or function). A Pointer points to the physical address of a
variable/object.
bye,
Oliver
R
ryadav
Adding to Oliver post, refferences should always be initialised,
pointer need not be.
they again have many adavantages and disadvantages...more given in book
pointer need not be.
they again have many adavantages and disadvantages...more given in book
S
Sandeep
ryadav said:
This is because a reference is an alias( as already mentioned ). So
this is not a different point that you are putting down.
Which book ? You are not initializing a _reference_ here
N
Neil Cerutti
When choosing a type to refer to an object:
Use a reference when you have to, like in copy constructors.
Use a reference when the referenced object will always exist.
Use a reference when the reference will not be changed to refer
to a different object.
Otherwise, use a pointer.
Apologies to Steve Meyers. See _More Effective C++_ for details.
G
Greg Comeau
Actually, it is a big difference. The concept of a reference
being an alias did not have to mean that it had to be initialized,
however, it was determined that for C++ that having it that way
was a good idea. Also, there are other ways in C++ to establish
aliases, and they do not have such a syntactic demand, perhaps
unfortunately.
S
Sandeep
Greg said:
If you see carefully I am reponding to the statement saying that apart
from being an alias, an _additional_ difference is that it needs to be
initialized. And while doing this I am giving the reason why it needs
to be initialized.
I agree to what you say about there being other ways to establish (
initialize
) a reference.When you say "The concept of a reference being an alias did not have
to mean that it had to be initialized", I guess we are trying to say
the same things. Apologies if I was not clear.
A
Al
Why do you often use constant references? What is the point of doing
that?
I heard of being faster because of not tranfering and copying the
object when called as argument... more details?
ex: T(const T& r): a(r.a), b(r.b) {} instead of T(T r): a(r.a), b(r.b)
{}
or many other cases
why is it so important to do it?
that?
I heard of being faster because of not tranfering and copying the
object when called as argument... more details?
ex: T(const T& r): a(r.a), b(r.b) {} instead of T(T r): a(r.a), b(r.b)
{}
or many other cases
why is it so important to do it?
N
Neelesh Bodas
Al said:
As far as "copying" etc is concerned, even references would be OK here,
not necessarily const.
One of the typical reasons of using const references is that literals
and temporaries cannot be passed as a non-const reference. Also, const
reference ensures that state of the object will not be changed inside
the function.
A
Al
does it make the program faster or does it take less memory?
D
deane_gavin
Al said:
Well you've got it really. The difference between your two examples
above is that the first does not need to make a copy whereas the second
does. If copying is non-trivial and you do not *need* a copy then why
waste time making one? Using a reference does not make the code any
harder to read - the idiom is extremely widespread and recognisable.
So that's the advantage of a reference. Why use a const reference?
Firstly, the compiler will prevent you from introducing bugs where you
try to modify the object [*] and secondly it allows you to pass const
objects and temporaries.
Gavin Deane
[*] If you need to be able to modify the object then you can't use a
const reference. If you need to modify a copy of the object but leave
the original untouched then you can't use a reference at all - you need
a copy. But if you don't need to modify the object at all, using a
const reference gets the compiler helping you achieve that. The
compiler is, after all, your friend.
K
Kaz Kylheku
Oliver said:
A reference isn't a name.
It's a specially attributed variable (local, global or member), which
is implemented as a hidden pointer to the real object.
A reference can be bound to an object which has no name.
int &x = * new int;
delete &x;
You can also have const references, which can be bound to non-lvalue
expressions. So not only does the subject of a reference not have to
have a name, it doesn't even have to be a first-class object:
void take_ref(const int &x);
take_ref(2 + 2);
If x above is ``another name'' for something, what is the original name
of that thing? To allow the above, C++ postulates the existence of a
temporary object that holds the result of 2 + 2.
So does a reference.
R
REH
Kaz Kylheku said:
References are not variables. They cannot be changes, nor does the standard
require that they be implemented in a particular way.
Where does that standard say that? A reference may not even exist as a
physical entity (i.e., not exist in memory) in a compiled program.
REH
K
Kaz Kylheku
REH said:
Indeed, a variable binding cannot be changed. You can change what it
contains, but not the binding itself!
When you execute the defintion
{
int x = 3;
}
x gets bound to a storage object which holds an int. You can't, in the
same context, rebind x to a different object.
A reference is the same way. It's a named binding to some object which
holds a value. The only difference is that the whereas x above gets a
fresh location in automatic storage, a reference variable gets a
binding to an existing object that could be in anywhere.
A variable is just an association between a name and a storage
location.
Something can be a physical entity without existing in memory. All
elements of the processing system are physical; registers are physical.
What you are talking about is an optimization. In the abstract
semantics, a reference locates an object. Locating objects is done by
means of their address. In the actual semantics, perhaps the location
can be inferred statically, and so the reference need not require any
run-time storage for its binding.
All kinds of things can be optimized away, including pointers. Given:
{
Type obj, *ptr = &obj;
// ...
}
suppose that ptr is never changed over that scope; it always points to
obj. Whenever you use ptr, the compiler can just change that to a
direct reference to obj. The ptr variable can be completely optimized
away so there are no traces of it in the translated image. Expressions
like ptr->memb may be translated in exactly the same way as
obj.memb.
That doesn't mean that ptr isn't a pointer object! We can discuss its
abstract semantics as a pointer object, without implying a particular
implementation in the actual semantics.
R
REH
Kaz Kylheku said:
None of which disputes what I said: References are not variables, nor do
they have to be implemented as "hidden pointers."
No, I am not talking about optimization. In this:
int x = 1;
int& y = x;
y may be completely "ignored" by the compiler, replacing it with x. No
pointer, no optimization removing said pointer.
You still have not shown where in the standard it says a reference must be
implemented as a pointer.
REH
G
Greg Comeau
Not in the sense of a name as in an identifier. But it certainly
does "names" something, akin to say how *p might name something.
This tends to dispute your previous claim.
Anyway, it need not only be local/global/member.
Which _may be_ implemented as a pointer.
And lvalue ones.
The expression itself.
As you note, it may be implemented as such, but as a concept,
it's certainly more along the lines of an alias -- even if the
original entity did not have a formal name. You could of course
make an argument that even in int i = 99; that i at some point(!)
"points" to/at the physical address along the line of a file in a
filesystem being a link to its storage even if it's the first link.
But unless I'm too tired to think right now, I think we disgress.
K
Kaz Kylheku
Greg said:
But p is a pointer. If that's the sense in which a reference is a name,
then you are saying it's a pointer.
The address space is a namespace in which addresses are names, yes.
Ah yes, I forgot that, for instance, function return values can be
references.
This was a dumb thing to say; I mean that it's semantically a pointer
to the real object. ``Implemented'' is a bad word. Even pointers (the
abstract data values) may not always be implemented as actual machine
pointers.
You can analyze a C++ program using an abstract model for references in
which they are represented in the same way as pointers. This model will
not lead you astray into any wrong conclusions about that program's
behavior.
In the abstract, every reference is data item containing the bits that
make up a pointer. If you think that, you will be able to reason
correctly about all situations involving references. At least, in a
working program. To precisely understand the mode of failure of a
broken program, you have to drag in actual semantics---of everything,
not just references.
Alias in the sense that if p and q are the same pointer, then *p and *q
designate aliased objects?
Pointers are aliases also, or at least the expresssions which
dereference them. References do that on their own, but that's just
syntactic sugar.
What if the reference is returned from a function? The reference has no
name in that case either, and you don't have to capture it as a
reference:
extern int &get_int();
int *p = &get_int();
Of course get_int has to return some bits that locate an integer that
lives somewhere in the run-time storage space. It could be anywhere!
Those bits are semantically a pointer. Perhaps the representation of
the reference isn't exactly the same as that of an ``int *'' in every
detail, but it's functionally identical. Certainly, it carries enough
information to produce an ``int *'' when we want it to, like above.
I can convert a pointer to a reference, and back to a pointer without
losing anything. And vice versa. So if either kind of value has extra
information in its representation that the other doesn't have, that
information isn't semantically important to the program.
int a;
int &b = a;
int *c = &b;
int &d = *c;
int *e = &d;
Now we have b and d which are references to a, and c and e which point
to a. Nothing was lost in the chain of initializations.
I could. But in that case I would say that resolving a reference
involves chasing two pointers. One to get to the box that contains the
pointer, and one to follow the reference.
K
Kaz Kylheku
REH said:
The y entity doesn't have to have a corresponding object in the
translation only because the conditions are right for that
optimization. Here is an example in which the conditions are not right:
extern void external_function(int **);
int x = 1;
int *p = &x;
external_function(&p);
int &y = *p;
p = ...;
Now what? When the reference y is made, p might no longer point to x.
So you cannot just statically replace all occurences of y by x.
After the reference is made, p is changed, so y and *p are not aliases
any longer either; you can't pretend that y is *p everywhere. (Of
course, you can emit code which performs a check, and branches to
alternate translations).
Do you still believe that there doesn't have to be any run-time
representation of y, such as a hidden local variable or a value in a
CPU register or whatever?
And doesn't that value have exactly the same operational semantics as a
pointer?
Note that we can convert a pointer to a reference, and vice versa,
without gaining or losing any information.
We can do this through external function calls, so there is no static
"cheating" going on:
extern int *ref_to_ptr(int &);
extern int &ptr_to_ref(int *);
int a = 42;
int *b = ref_to_ptr(a);
int &c = ptr_to_ref(&b);
int *d = ref_to_ptr(b);
int &e = ptr_to_ref(d);
b, c, d, and e all refer to a. This works even if these functions are
in a separate translation unit.
Yawn... anyway, this is boring me to death.
Either you recognize syntactic sugar for what it is, or you don't.
See the code above. However a reference is implemented, it must be
capable of carrying all of the information that a pointer does. and not
only that, but just like a pointer, a reference is capable of producing
an expression that aliases for the object. If a reference is made from
a pointer p, then it aliases for exactly the same object that the
expression *p designates. From the program's point of view, a reference
carries not a bit more or less information than a pointer and it not
only carries that information, but also performs the same job of
locating an object.
Hey, if the compiler wants to do something different in the
representation, I don't care; I can't tell from the abstract semantics.
Maybe the bits in a reference are all shifted around or inverted so
that bit operations have to be done to convert between pointers and
references. Invisible to me, don't care.
If it walks like a duck, quacks like a duck, and moreover you can
cross-breed it with a duck such that ducklings are produced which can
have more ducklings, it's very probably a duck.