473,320 Members | 1,930 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

references - how is it useful

I know how to use references but i DO not get WHY they exist other than
to add to the language. Are they actually needed for anything?

Nov 22 '05 #1
11 1930
> I know how to use references but i DO not get WHY they exist other than
to add to the language. Are they actually needed for anything?


Since they're basically pointers in disguise, they're not really
needed, they just add some "beauty"/logical structure...
Nov 22 '05 #2

"Sven Hesse" <dr*****@users.sourceforge.net> wrote in message
news:sl********************@tchibo.coffee.org...
I know how to use references but i DO not get WHY they exist other than
to add to the language. Are they actually needed for anything?


Since they're basically pointers in disguise, they're not really
needed, they just add some "beauty"/logical structure...


It's not possible to overload operators without them.

-Mike
Nov 22 '05 #3

Sven Hesse wrote:
I know how to use references but i DO not get WHY they exist other than
to add to the language. Are they actually needed for anything?


Since they're basically pointers in disguise, they're not really
needed, they just add some "beauty"/logical structure...

References are needed as a return type for operator =, so that x = y =
z works as expected, etc. There may be a few other places where they
are truly needed.

Everywhere else, in general, they are useful because you can't override
operators on the pointers, so using references keeps things as
'objects'. Of course, in most of those cases, you could dereference,
but yeah, it would get ugly.

Nov 22 '05 #4
References are needed as a return type for operator =, so that x = y =
z works as expected, etc. There may be a few other places where they
are truly needed.
Hmm, yeah, you're right, I haven't thought of operators, I should think
before answering next time... ^^;

(Though if the language were designed that way, you could do that with
pointer... *duck*)
but yeah, it would get ugly.


Agreed...
Nov 22 '05 #5
REH

Sven Hesse wrote:
I know how to use references but i DO not get WHY they exist other than
to add to the language. Are they actually needed for anything?


Since they're basically pointers in disguise, they're not really
needed, they just add some "beauty"/logical structure...


How would you define an operator returning an lvalue without them?

Nov 22 '05 #6
KK

co************@gmail.com wrote:
I know how to use references but i DO not get WHY they exist other than
to add to the language. Are they actually needed for anything?

In some cases it gives added security over pointers. For example, the
address of a pointer can be changed which can be avoided with
reference.

Nov 22 '05 #7
On Mon, 21 Nov 2005 21:10:38 +0000 (UTC), Sven Hesse
<dr*****@users.sourceforge.net> wrote:
I know how to use references but i DO not get WHY they exist other than
to add to the language. Are they actually needed for anything?


Since they're basically pointers in disguise, they're not really
needed, they just add some "beauty"/logical structure...


No, they aren't pointers! This is just one more of those "urban myths"
which refuse to die. The C++ standard does not require a compiler to
allocate storage for a reference (section 9.3.2, paragraph 3). Just
because some compilers implement references as pointers doesn't mean
that *all* compilers do it that way, or if they do it sometimes, they
don't have to do that in every situation. And besides, we shouldn't
care how it is actually implemented. A compiler might reserve 1 MB of
storage for each reference for all we know, and it could still be a
"conforming implementation". You cannot know either because sizeof()
with a reference returns the size of the object aliased, not of the
reference itself.

It also implies that compilers can take more liberty to optimize away
a reference and deal directly with the object for which it is an
alias. That's why it is not possible to take the address of a
reference, whereas a pointer will always occupy some bytes of storage
(unless it is optimized away). Finally, it is the reason why there can
be no "null references".

As others have already pointed out, there IS a real need for
references aside from what one can do with pointers.

--
Bob Hairgrove
No**********@Home.com
Nov 22 '05 #8
On 21 Nov 2005 19:33:53 -0800, "Kaz Kylheku" <kk******@gmail.com>
wrote:

Bob Hairgrove wrote:
On Mon, 21 Nov 2005 21:10:38 +0000 (UTC), Sven Hesse
<dr*****@users.sourceforge.net> wrote:
>> I know how to use references but i DO not get WHY they exist other than
>> to add to the language. Are they actually needed for anything?
>
>Since they're basically pointers in disguise, they're not really
>needed, they just add some "beauty"/logical structure...
No, they aren't pointers! This is just one more of those "urban myths"
which refuse to die.


I'm not an idiot, nor perpetrator for myths, yet I will insist that
they are.


You can insist anything you like, and so can I ... but that doesn't
really make a difference about how things really are. So let's have
some more fun here... ;)
The C++ standard does not require a compiler to
allocate storage for a reference (section 9.3.2, paragraph 3).


The C++ standard does not require a compiler to allocate storage for
other things either. Integers, pointers, etc.


It does if I take the address of an object (instance) of one of these
types or otherwise use it in some meaningful way.
Just
because some compilers implement references as pointers doesn't mean
that *all* compilers do it that way, or if they do it sometimes, they


Name one compiler which doesn't implement a reference as a pointer,
when that reference is returned from an external function, or when it's
embedded in a struct or class.


This is the standard come-back: "Name one that doesn't!", and I am
tired of hearing it. I don't have time to disassemble the code
produced by the three or four compilers I regularly use in order to
see how this is done, and even if I did that for one function or
class, I couldn't be sure that the same compiler would always do it
the same way. Besides, as long as I can't use the reference any
differently than an object, I don't care -- more importantly, I don't
*have to* care. Fine with me if the assembly code shows that pointers
are used here. Why do YOU care so much, BTW?

As to reference members in a struct or class, I'd like to point out
that the standard disallows a pointer-to-member if that member has
reference type (hmm ... must be a good reason for that somewhere...).
don't have to do that in every situation. And besides, we shouldn't
care how it is actually implemented. A compiler might reserve 1 MB of
storage for each reference for all we know, and it could still be a
"conforming implementation".


It could also reserve that storage for a pointer and be a conforming
implementation. So what?


Exactly. Or it could reserve 0 bytes instead. So what?
References are /semantically/ pointers. They are functionally
indistinguishable from pointers.

A reference can be converted to a pointer, and a pointer to a
reference, without any loss of information.
Where do you get your strong guarantee that this statement is true?
The C++ standard supplies no such guarantee. As a matter of fact,
there is even a paragraph *warning* us that it is unspecified whether
or not storage is allocated for a reference. Why do you think that
sentence was deemed necessary by the standards committee? The standard
document is certainly thick enough already without meaningless text
thrown in.
You cannot know either because sizeof()
with a reference returns the size of the object aliased, not of the
reference itself.


Who cares? You do know that a reference can store a pointer, and that
you can retrieve that original pointer from it. You also know that a
reference will fetch the object for you that is pointed to. These
properties are enough to identify it as being, operationally, a
pointer.

There is a recent thread about this; I'm not going to repeat all the
arguments I made.


I'd like to see a link to it. No need to repeat anything.
It also implies that compilers can take more liberty to optimize away
a reference and deal directly with the object for which it is an
alias.


Compilers have exactly the same liberty as with a pointer. There is an
extra piece of information that is statically know about a reference,
without doing any analysis: that the pointer can't be reseated. The
same thing can be known about a pointer, under similar circumstances.

Moreover, a pointer can be const-qualified, so then it is statically
attributed as unmodifiable.

int x;
int *p const = &x;

Now, *p is an alias for x. Because p is const, we don't have to scan
the scope for modifications to p, we can just assume that it always
points to x. Right in the abstract syntax tree, we can replace *p
occurences with x.

If the address of p is taken and escapes into some nonlocal context
then we have to allocate an object for it. Big deal.
That's why it is not possible to take the address of a
reference,


One reason that is not possible is that a reference isn't a type. So
the resulting expression could not be mapped into the type system
(other than as, say, a pointer-to-pointer).

You could easily extend the language with a special address-of operator
that gives you a pointer-to-pointer to the cell that holds the
reference. Of course, the compiler would then have to ensure that there
is something to point to.

There is no unary && so it would fit the bill quite nicely.

int &x;
int **pref = &&x; // New! extra-strength address-of!

I like it!


I think it sucks, big time.
I say make it a pointer to a non-const pointer, so you
could reseat the reference:

*pref = &y; // I could use something like this from time to time!

This feature could be added to C++ without semantically conflicting
with anything.
whereas a pointer will always occupy some bytes of storage
(unless it is optimized away).
And a reference will always occupy some bytes of storage (unless it is
optimized away).


How do you know? You are generalizing from specifics and have nothing
to back it up.
Everything occupies bytes of run-time storage unless it's optimized
away.

Where is the difference?

A compiler can't blindly optimize away references. Only ones that are
created under the right circumstances.
Finally, it is the reason why there can
be no "null references".
Yes there can. Dereference a null pointer and bind a reference to that
lvalue:

int &x = *(int *) 0;

Is this well-defined or not? It doesn't matter. Because the answer to
that question is a double-edged sword. If it's well-defined, it means
you can have null references. If it's undefined, it's worse because you
can still have null references by virtue of abusing the language
implementation through undefined behavior.


Dereferencing a null pointer is always undefined behavior...the minute
it happens.
You can express the idea of creating a null reference, and C++
compilers take it without complaint.

Not only can there be null references, there can be invalid references.
int &x = *p = new int;
delete p; // x is now a dangling reference

Consequently, references must be regarded with the same caution and
respect as pointers. Since that's what they freaking are!


It's not so. Dangling references can be a problem, but so can dangling
pointers, integer overflow, buffer overruns, floating-point rounding
errors, etc., etc. -- in short, just about any programming error you
can name. And it's much more common to encounter dangling pointers
than dangling references, and there is a reason for this.

If have a function which takes a reference argument, inside the scope
of the body of that function I can always assume that the reference is
valid. If it isn't, then the *caller* will get undefined behavior.
It's not the responsibility of the *callee* receiving the reference to
check its validity, it's the responsibility of the caller to provide a
valid reference. This is different with pointers. Because the
*language* doesn't prohibit passing a null pointer to a function as an
argument, I have to check *inside the function* whether I can use it
or not. This is not so with references. Anyone who wastes processor
cycles writing checks like the following is just plain silly:

void func(int& ri) {
if (&ri) {
ri = 4711;
}
else {
// naughty, naughty! ...
}
}

As to passing a dangling reference, I suppose there is always that
chance. But what are you going to do about it? What are you going to
do about dangling pointers? Is there any way that is safer than a
dangling reference?

--
Bob Hairgrove
No**********@Home.com
Nov 23 '05 #9
On 2005-11-22, Kaz Kylheku <kk******@gmail.com> wrote:
Bob Hairgrove wrote:
On Mon, 21 Nov 2005 21:10:38 +0000 (UTC), Sven Hesse
<dr*****@users.sourceforge.net> wrote:
>> I know how to use references but i DO not get WHY they
>> exist other than to add to the language. Are they actually
>> needed for anything?
>
>Since they're basically pointers in disguise, they're not
>really needed, they just add some "beauty"/logical
>structure...


No, they aren't pointers! This is just one more of those
"urban myths" which refuse to die.


I'm not an idiot, nor perpetrator for myths, yet I will insist
that they are.


You seem to be confused between an "is a" relationship and an "is
implemented in terms of" relationship.

--
Neil Cerutti
Nov 23 '05 #10
Bob Hairgrove wrote:
On 21 Nov 2005 19:33:53 -0800, "Kaz Kylheku" <kk******@gmail.com>
wrote:

Bob Hairgrove wrote:
On Mon, 21 Nov 2005 21:10:38 +0000 (UTC), Sven Hesse
<dr*****@users.sourceforge.net> wrote:

>> I know how to use references but i DO not get WHY they exist other than
>> to add to the language. Are they actually needed for anything?
>
>Since they're basically pointers in disguise, they're not really
>needed, they just add some "beauty"/logical structure...

No, they aren't pointers! This is just one more of those "urban myths"
which refuse to die.
I'm not an idiot, nor perpetrator for myths, yet I will insist that
they are.


You can insist anything you like, and so can I ... but that doesn't
really make a difference about how things really are. So let's have
some more fun here... ;)
The C++ standard does not require a compiler to
allocate storage for a reference (section 9.3.2, paragraph 3).


The C++ standard does not require a compiler to allocate storage for
other things either. Integers, pointers, etc.


It does if I take the address of an object (instance) of one of these
types or otherwise use it in some meaningful way.


If conditions are such and such, then something has to be done to make
the semantics work. No kidding!

References also become real storage objects under some circumstances.
Their address can be taken implicitly. If a struct or class contains a
reference, and I have a pointer to an instance of that struct or class,
then, indirectly, I have an address of that reference, (modulo some
displacement that may be zero).

So, references sometimes exist in the run-time environment as storage
objects in memory, and sometimes they disappear in the translation.

Exactly the same thing can be said about other kinds of values.
Fine with me if the assembly code shows that pointers
are used here. Why do YOU care so much, BTW?
Because I disagree with the blatant misinformation being pushed around
that references are not pointers. They aren't pointers in the type
system, but they are operationally equivalent to pointers and they are
real run-time objects except when optimized away.
As to reference members in a struct or class, I'd like to point out
that the standard disallows a pointer-to-member if that member has
reference type (hmm ... must be a good reason for that somewhere...).
It also disallows a regular pointer! If you take the address, you get
the target object.

Of course there is a good reason! References are not represented in the
type system.

There is no way you can even syntatically express pointer-to-reference
or pointer-to-member-reference. The type construction syntax isn't
valid.

But the reference is there in that object.

You also can't make pointers to bitfields. That doesn't mean they
aren't storage.
don't have to do that in every situation. And besides, we shouldn't
care how it is actually implemented. A compiler might reserve 1 MB of
storage for each reference for all we know, and it could still be a
"conforming implementation".


It could also reserve that storage for a pointer and be a conforming
implementation. So what?


Exactly. Or it could reserve 0 bytes instead. So what?


It could not reserve zero bytes if the object cannot be optimized away.
If storage is needed for the reference, then it has to be large enough
to hold all the same information as a pointer.
A reference can be converted to a pointer, and a pointer to a
reference, without any loss of information.


Where do you get your strong guarantee that this statement is true?


In the perfectly well-formed, conforming code I can write to
demonstrate it.

extern int &ptr_to_ref(int *);
extern int *ref_to_ptr(int &);

int a = 42;
int *b = ref_to_ptr(a);
int &c = ptr_to_ref(b);
int *d = ref_to_ptr(c);
int &e = ptr_to_ref(d);

Now b, c, d and e all refer to a. Their initializing values were
smuggled through external functions, which can be trivially defined
like this:

int &ptr_to_ref(int *ptr) { return *ptr; }
int *ref_to_ptr(int &ref) { return &ref; }
The C++ standard supplies no such guarantee.
The C++ doesn't make guarantees; vendors do.

The C++ standard does require the above conversions to work.

It shows that we can freely convert between a pointer and a reference,
and that we can do this through an external data pathway: a blackbox
where we pass in a reference and get a pointer back or vice versa.

The only sticking point is that a null pointer can't be smuggled
through this conversion system because of the null dereference problem.
So there is one value that references don't have in their domain
compared to pointers. In practice, you can coax null references out of
your compiler. It's quite portable and harmless.
As a matter of fact,
there is even a paragraph *warning* us that it is unspecified whether
or not storage is allocated for a reference.
I have found it, it: "It is unspecified whether or not a reference
requires storage."

"Unspecified" is a normative term. It means that a choice must be made
among alternative requirements, without any documentation!
Why do you think that
sentence was deemed necessary by the standards committee?


That sentence says absolutely nothing.

It says that a choice must be made between among a set of alternatives
which exhaustively partition the space of all possibilities.

The same requirement (or absence of requirement) can be made simply by
omitting such a sentence.

If you erase the sentence, the implementor must still decide whether or
not a reference requires storage. And the implementor is still free not
to document anything about that choice.

The only situations when it's useful to explicitly say that something
is unspecified, rather than leave a lack of specification, is when it
might be mistakenly assumed that the behavior is specified, with dire
consequences.

A good example of this is the evaluation of function arguments. The
order is unspecified. If that isn't spelled out, implementors, or more
likely users of the language, might mistakenly assume that the order is
left to right.

It's very easy to write code which depends on that order of evaluation.
That code doesn't even have to invoke undefined behavior. For instance:

x(f(), g(), h());

results in the functions f, g and h being called in one of six possible
orders, each possibility being well-defined behavior.

So in other words, the behavior of a correct program can differ because
of this unspecified behavior. A correct test case can be written which
reports which way the choice went.

To write code that depends on whether or not a reference has storage,
you'd have to write some dubious construct, whose behavior is undefined
regardless of whether or not references have storage.

So it's not useful to spell this out at all.
whereas a pointer will always occupy some bytes of storage
(unless it is optimized away).


And a reference will always occupy some bytes of storage (unless it is
optimized away).


How do you know? You are generalizing from specifics and have nothing
to back it up.


How do I know? Namely that the sentence I have written covers the
entire space of logical possibilities.

Either the object occupies run-time storage, or it doesn't.

P or not P

Always true!

Nov 23 '05 #11
Sven Hesse <dr*****@users.sourceforge.net> writes:
References are needed as a return type for operator =, so that x = y =
z works as expected, etc. There may be a few other places where they
are truly needed.


Hmm, yeah, you're right, I haven't thought of operators, I should think
before answering next time... ^^;

(Though if the language were designed that way, you could do that with
pointer... *duck*)


If the language were designed in a slightly different way we would
have APL instead of C++...

/Niklas Norrthon
Nov 23 '05 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

17
by: Tom | last post by:
The motivation for references seems clear: stop people from using nasty pointers when all they really want is a reference to an object. But C++ references are so inadequate that I'm still using...
37
by: Dave | last post by:
Hello all, Please consider the code below. It is representative of a problem I am having. foo_t needs to contain a bar_t which is a class without a copy constructor or operator=. It is not...
26
by: Desmond Liu | last post by:
I've read articles like Scott Meyer's EC++ (Item 22) that advocate the use of references when passing parameters. I understand the reasoning behind using references--you avoid the cost of creating...
7
by: Dave Townsend | last post by:
Hi, I came across a little problem the other day, I wonder if anyone has a more elegant solution: I have a class which has some "pixmap" members, this is a QT-data type which is similar to a...
3
by: Scott Simonson | last post by:
When in the code editor I select TOOLS | REFERENCES I get a list of references. Mainly DLLs that are accessible. Well I assume that they are all accessible. Besides the ones I have to use or might...
2
by: S. van Beek | last post by:
Dear reader, For removing a reference in the VBA reference form I receive from Doug Steele the following code: ........... References.Remove refCurr
30
by: jeremygetsmail | last post by:
I've got an adp (Metrix.adp) with a reference to another adp (InteractSQL.adp). InteractSQL sits on a server, and is refered to by all of the clients (Metrix), which sit on the client machines...
28
by: Frederick Gotham | last post by:
When I was a beginner in C++, I struggled with the idea of references. Having learned how to use pointers first, I was hesitant to accept that references just "do their job" and that's it. Just...
9
by: igor.kulkin | last post by:
References is a relatively basic feature of C++ language. It might be a good thing to think of references as aliases to the variables. However it's good to think of references this way when you...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.