Assigning to references

[Andrey Tarasevich]

...
I had sent an earlier post that for some reason didn't get through (and some
of you may have noticed that for some reason, my original post got posted
twice; sorry about that...).
...

You cross-posted your first post to 'comp.lang.c++.moderated', which is
as pre-moderated conference. It takes quite some time for your post to
go through the moderation queue and appear in the conference (much
longer than in case of non-moderated conference as 'comp.lang.c++'). The
important detail here is that such post will not appear in _any_ of the
conferences you sent it to until it is approved by
'comp.lang.c++.moderated'. That's why your second post on the same
subject (sent to 'comp.lang.c++' only) appeared here much sooner.

Is there some sort of treacherous trick that would allow us to get the
address of the reference (as opposed to the referent)? Is a reference even
guaranteed to *have* an address, or might it be just a simple compile-time
alias for the referent?

In general case the reference is not guaranteed to occupy any memory,
which means that in general case it doesn't have an address.

In some other particular practical cases the reference will be
implemented as "a pointer in disguise" and will occupy memory. In such
cases it is probably possible to gain access to the reference itself and
modify it, but i'm pretty sure that even the most hardcore language
"hackers" will agree that practical value of such technique is zero or
even less.

 

[Ron]

One poster mentioned the possibility of re-binding a reference by destroying

the old rerferent with a manual destructor call and then using placement new
to construct the new object in the same memory. Though ill-advised, this
does sound like a standard-conforming way to do it.

Yeah, it's conformant -- and yeah, it's ill-advised. See s.3.8(7) for
what the Standard does with it.

This got me to wondering...

Is there some sort of treacherous trick that would allow us to get the
address of the reference (as opposed to the referent)? Is a reference even
guaranteed to *have* an address, or might it be just a simple compile-time
alias for the referent? I'd be interested to here any thoughts on all of
this...

References don't have addresses. s.8.3.2(4)("There shall be no
references to references, no arrays of references, and no pointers to
references.") References are merely aliases for the things to which
they're bound.

-Ron

 

[Ron Natalie]

Yeah, it's conformant -- and yeah, it's ill-advised. See s.3.8(7) for
what the Standard does with it.

Of course, one had better make sure the reference isn't bound to a derived
class before attempting that game.

 

[Allan W]

In general case the reference is not guaranteed to occupy any memory,
which means that in general case it doesn't have an address.

In some other particular practical cases the reference will be
implemented as "a pointer in disguise" and will occupy memory. In such
cases it is probably possible to gain access to the reference itself and
modify it, but i'm pretty sure that even the most hardcore language
"hackers" will agree that practical value of such technique is zero or
even less.

Just for grins, I did this. I created a class with a member that was
a reference, in such a way that I could figure out the address of the
reference. Then I modified the value in that reference and observed
that the reference had indeed been "re-seated."

Take it for what little it's worth. I am 100% certain that this is
not standard-compliant, because I had to exceed the bounds of an
array in order to find that address. Note that even though I set up
a situation in which I knew that the compiler did HAVE to create a
"pointer in disguise," there was still a huge risk that it wouldn't
work right (or it won't work right in future versions of the same
compiler, or that it won't even work in this version with different
compile options). Essentially what I did was to change the value in
some memory that I wasn't supposed to touch. The compiler may have
assumed that this memory couldn't have been changed, and used this
to "optimize" the code -- in which case, had my program run a
little bit longer, it conceivably could have broken.

This is NOT something I plan to put on a resume. In fact, I wish I
hadn't done it. I feel dirty now, like I need a shower. The truth
is, I never even did it -- I don't know who figured out my Google
password, but it wasn't me who even said this.

Please, Dave, I beg you -- don't bother figuring out how it's done.
Forget the whole idea. Just use pointers like everyone else that
can be proud of their code.

 

[stelios xanthakis]

In general case the reference is not guaranteed to occupy any memory,
which means that in general case it doesn't have an address.

In some other particular practical cases the reference will be
implemented as "a pointer in disguise" and will occupy memory. In such
cases it is probably possible to gain access to the reference itself and
modify it, but i'm pretty sure that even the most hardcore language
"hackers" will agree that practical value of such technique is zero or
even less.

Hi.

I've been thinking about references (lwc) and I came up with this
idea in order to be able to change their value:

Something like an unary pseudo-operator called "dereference (EXPR)".
For the EXPR in the parentheses, references will be taken as
pointers (compiler will not magically convert them to (*var)).

For example:

int i, j;
int &ri = i, &rj = j;

// same as i=3
ri = 3;

// same as i=j
ri = rj;

// dereference. ri points to same thing with rj
dereference (ri = rj);

// make rj point to i
dereference (rj) = &i;

This is very easy to implement in a compiler, provided that
references are implemented as "pointers in disguise" indeed.

Hmmm. Good, average or terrible idea?

stelios.

 

[Ragnar]

One poster mentioned the possibility of re-binding a reference by destroying
the old rerferent with a manual destructor call and then using placement new
to construct the new object in the same memory. Though ill-advised, this
does sound like a standard-conforming way to do it. This got me to
wondering...

Is there some sort of treacherous trick that would allow us to get the
address of the reference (as opposed to the referent)? Is a reference even
guaranteed to *have* an address, or might it be just a simple compile-time
alias for the referent? I'd be interested to here any thoughts on all of
this...

When you get down to the shanties, everything has an address. A C++
reference is usually implemented as a pointer. And if i restrict my
discussion to the IA-32 architecture, then a reference IS implemented
as a pointer. If you want to really understand references, then just
interface with a small assembly language program. All the mystique of
references will melt away.

References are a very usefull HLL tool. They support pass-by-address
semantics, with the pass-by-value syntactics. They are aliases and
lvalues. And one does not have to deal with the *muck* of the pointers
(though, some, like Yours Truly like wallowing in that sort of muck).
But this hiding of the pointer syntax with the nice references, puts
restrictions on you (within the C++ type system). Some might even say
that it is just a syntactic sugar.

Statement like 'one cannot take the address of the reference' are a
bit misleading. I remember reading this in Herb Schildt's C++: The
complete reference. This, if one thinks in C++, implies that one
cannot apply the address of operator, &, to references, which is
incorrect. A semantically precise statement is that references are
aliases, and that all the operations on a reference variable are
actually done on the referend (which also answers your original
question). So when you take the address of a reference, you get the
address of the referend, which is semanticallly precise.

Think of a reference as a label. So if you declare a variable, say int
i, and you want the address of i, then what you get is the address of
the object pointed to by i (the int), not of the label i. Labels do
not have addresses anyway in C++. So now if you declare a reference,
say int & ri = i; then think that ri is another label. And to be
consistent, you can't get the address of this new label any more than
you can of the old. This new label has some additional properties, but
that is another story.

In case you can only use C++, declare a class which has only one
member: a reference, and no virtual functions. This reference is
initialised from the initialisation list in the ctor. Then the adress
of the class will be the address of the reference. Use some old
C-style casts, to get what you want.

 

[Dave]

Hi.

I've been thinking about references (lwc) and I came up with this
idea in order to be able to change their value:

Something like an unary pseudo-operator called "dereference (EXPR)".
For the EXPR in the parentheses, references will be taken as
pointers (compiler will not magically convert them to (*var)).

For example:

int i, j;
int &ri = i, &rj = j;

// same as i=3
ri = 3;

// same as i=j
ri = rj;

// dereference. ri points to same thing with rj
dereference (ri = rj);

// make rj point to i
dereference (rj) = &i;

This is very easy to implement in a compiler, provided that
references are implemented as "pointers in disguise" indeed.

Hmmm. Good, average or terrible idea?

stelios.

On the surface, it does sound like a useful idea. It would be nice to be
able to re-bind a reference. Although, until a lot of thought was applied,
it would leave me uneasy simply because C++ is a very, very rich language
and the different features of the language sometimes interact in surprising
or non-apparent ways. Might it be that adding the ability to re-bind a
reference might cause other problems in the language? Maybe there's nothing
to what I'm saying, but the cautious side of me says that to mess with
something as complex as C++ requires a *lot* of due dilligence and
forethought. Even then, something might be missed! But barring any such
deep ramifications, I would indeed like such a feature to be available! Now
getting the standards committee to consider it might be a bit of a
challenge!!!

 

[Dave]

When you get down to the shanties, everything has an address. A C++
reference is usually implemented as a pointer. And if i restrict my
discussion to the IA-32 architecture, then a reference IS implemented
as a pointer. If you want to really understand references, then just
interface with a small assembly language program. All the mystique of
references will melt away.

References are a very usefull HLL tool. They support pass-by-address
semantics, with the pass-by-value syntactics. They are aliases and
lvalues. And one does not have to deal with the *muck* of the pointers
(though, some, like Yours Truly like wallowing in that sort of muck).
But this hiding of the pointer syntax with the nice references, puts
restrictions on you (within the C++ type system). Some might even say
that it is just a syntactic sugar.

Statement like 'one cannot take the address of the reference' are a
bit misleading. I remember reading this in Herb Schildt's C++: The
complete reference. This, if one thinks in C++, implies that one
cannot apply the address of operator, &, to references, which is
incorrect. A semantically precise statement is that references are
aliases, and that all the operations on a reference variable are
actually done on the referend (which also answers your original
question). So when you take the address of a reference, you get the
address of the referend, which is semanticallly precise.

Think of a reference as a label. So if you declare a variable, say int
i, and you want the address of i, then what you get is the address of
the object pointed to by i (the int), not of the label i. Labels do
not have addresses anyway in C++. So now if you declare a reference,
say int & ri = i; then think that ri is another label. And to be
consistent, you can't get the address of this new label any more than
you can of the old. This new label has some additional properties, but
that is another story.

In case you can only use C++, declare a class which has only one
member: a reference, and no virtual functions. This reference is
initialised from the initialisation list in the ctor. Then the adress
of the class will be the address of the reference. Use some old
C-style casts, to get what you want.

This idea, as suggested by you and one other poster, is interesting! I
think I'll try it for kicks, but as was also stated in this thread, it's not
going on my resume (or in any production code)!!!

Thanks for the thoughts everyone!

 

[Victor Bazarov]

But I take it you can put a reference as a data member of a class and in
creating an instance set the reference using a parameter.
This would satisfy assignment of a reference at runtime, wouldn't it?

No. It's not "assignment". It's "initialisation". Look it up.

Victor

 

[Gary Labowitz]

On the surface, it does sound like a useful idea. It would be nice to be
able to re-bind a reference. Although, until a lot of thought was applied,
it would leave me uneasy simply because C++ is a very, very rich language
and the different features of the language sometimes interact in surprising
or non-apparent ways. Might it be that adding the ability to re-bind a
reference might cause other problems in the language? Maybe there's nothing
to what I'm saying, but the cautious side of me says that to mess with
something as complex as C++ requires a *lot* of due dilligence and
forethought. Even then, something might be missed! But barring any such
deep ramifications, I would indeed like such a feature to be available! Now
getting the standards committee to consider it might be a bit of a
challenge!!!

But I take it you can put a reference as a data member of a class and in
creating an instance set the reference using a parameter.
This would satisfy assignment of a reference at runtime, wouldn't it?

 

[=?iso-8859-1?Q?Juli=E1n?= Albo]

stelios xanthakis escribió:

Something like an unary pseudo-operator called "dereference (EXPR)".
For the EXPR in the parentheses, references will be taken as
pointers (compiler will not magically convert them to (*var)).

Use a pointer, no magic required.

Regards.

 

[Andrey Tarasevich]

...
When you get down to the shanties, everything has an address.

No. Only those entities that occupy storage (at least at conceptual
level) have addresses. Entities that don't occupy storage can't have
addresses.

A C++
reference is usually implemented as a pointer. And if i restrict my
discussion to the IA-32 architecture, then a reference IS implemented
as a pointer.

No. When the compiler sees the need to allocate storage for a reference,
then it is implemented as a pointer. When the compiler doesn't see the
need to allocate storage, reference is not implemented as a pointer and
has no place in the storage.

If you want to really understand references, then just
interface with a small assembly language program. All the mystique of
references will melt away.

While understanding of inner workings of the compiled program could be
very useful, it is important to know the difference between
language-level concepts and machine-level concepts.

References are a very usefull HLL tool. They support pass-by-address
semantics, with the pass-by-value syntactics. They are aliases and
lvalues. And one does not have to deal with the *muck* of the pointers
(though, some, like Yours Truly like wallowing in that sort of muck).
But this hiding of the pointer syntax with the nice references, puts
restrictions on you (within the C++ type system). Some might even say
that it is just a syntactic sugar.

Statement like 'one cannot take the address of the reference' are a
bit misleading. I remember reading this in Herb Schildt's C++: The
complete reference. This, if one thinks in C++, implies that one
cannot apply the address of operator, &, to references, which is
incorrect.

It doesn't necessary mean exactly that. This statement is ambiguous,
when taken out of context. I think that within the context of this
discussion everyone understands what is meant under "one cannot take the
address of the reference". It was explained in great detail in previous
replies.

Just like when C++ standard says that "object of array type cannot be
modified", we all understand what it really means. Although for an
unprepared reader it might sound like C++ standard prohibits, for
example, assignment to array's elements.

A semantically precise statement is that references are
aliases, and that all the operations on a reference variable are
actually done on the referend (which also answers your original
question). So when you take the address of a reference, you get the
address of the referend, which is semanticallly precise.

Think of a reference as a label. So if you declare a variable, say int
i, and you want the address of i, then what you get is the address of
the object pointed to by i (the int), not of the label i.

Of course. "Label i" does not occupy storage. It doesn't have a address.

Labels do not have addresses anyway in C++.

Labels (as they were informally defined above) _can't_ have addresses in
any language. It has nothing to do with C++.

So now if you declare a reference,
say int & ri = i; then think that ri is another label. And to be
consistent, you can't get the address of this new label any more than
you can of the old. This new label has some additional properties, but
that is another story.

In case you can only use C++, declare a class which has only one
member: a reference, and no virtual functions. This reference is
initialised from the initialisation list in the ctor. Then the adress
of the class will be the address of the reference. Use some old
C-style casts, to get what you want.

Not necessarily. In general case the compiler will be forced to
implement this reference as a pointer. In certain particular cases it
might be able to do perfectly fine without it.

 

[Ron]

One poster mentioned the possibility of re-binding a reference by

Of course, one had better make sure the reference isn't bound to a derived
class before attempting that game.

Quite. And, in general, there's no way to know. Also, of course, this
nasssty treacherous trick requires that you know what constructor
parameters to pass to the placement new, and that the old object's
destructor not have side-effects that make the operation invalid
(like, for example, unlocking a mutex), and....

-Ron

 

[lilburne]

In some other particular practical cases the reference will be
implemented as "a pointer in disguise" and will occupy memory. In such
cases it is probably possible to gain access to the reference itself and
modify it, but i'm pretty sure that even the most hardcore language
"hackers" will agree that practical value of such technique is zero or
even less.

It all depends on the motivatation:
http://www.afralisp.com/vbaa/unmain.htm

 

[Gary Labowitz]

No. It's not "assignment". It's "initialisation". Look it up.

Yes, of course, but what I am saying is: Can you set up a class with a
reference member, initialize it when the object is created and then use it.
By creating a new object of that class anytime you want to dynamically
"assign" that reference it satisfies the OP's question. Doesn't it?

 

[stelios xanthakis]

On the surface, it does sound like a useful idea. It would be nice to be
able to re-bind a reference. Although, until a lot of thought was applied,
it would leave me uneasy simply because C++ is a very, very rich language
and the different features of the language sometimes interact in surprising
or non-apparent ways. Might it be that adding the ability to re-bind a
reference might cause other problems in the language?

Could. First of all I think we should see differently references in
arguments and local/global reference variables. Most C++ books I've
seen say that local/global reference variables are of little use.

References are extremely useful in function arguments and return
value. It is a language feature I think that you cannot take the
address of a reference and that it there for our protection. For example
int foo (int&)
int bar ()
{
int i;
foo (i);
}

Here references guarantee that foo will not store the address of 'i'
in a place which will remain there *after* bar has returned, causing
lots of trouble.

Reference variables on the other hand are kind of "disabled" due to
the fact that they cannot be reassigned. The problem seems to be
just syntactical: How can you tell that this operation doesn't happen
to what the reference points to, but to the reference itself?
Right now the answer is: You can't. Use a pointer instead.

Allowing to "dereference" references gives more interesting possibilities
(for example: dereference (ri == rj), to see that references point to
same thing), and more ways to screw up (for example: delete dereference ri).
So one factor is whether we believe that the people using the language
have consciousness of what they're doing and they're not drunken.

Anyway, I do agree that the comitee thinks about those things much deeper.
Discussions in newsgroups may give them interesting ideas though.


Stelios

 

[Nils Petter Vaskinn]

int foo (int&)
int bar ()
{
int i;
foo (i);
}

Here references guarantee that foo will not store the address of 'i' in
a place which will remain there *after* bar has returned, causing lots
of trouble.

Eh?

void store_pointer(int*);

int foo (int& x) {
store_pointer(&x);
}

Allowing to "dereference" references gives more interesting
possibilities (for example: dereference (ri == rj), to see that
references point to

if (&ri == &rj) {
printf("ri and rj reference the same object\n");
}

same thing), and more ways to screw up (for example: delete dereference
ri). So one factor is whether we believe that the people using the
language have consciousness of what they're doing and they're not
drunken.

The point of references is that you can conveniently make a function that
is called without performing copying of it's parameters and can modify the
actual parameters (instead of a copy of them) without having to muck about
with pointer syntax.

compare:

void add42(int* value) {
*value +=42;
}

void add42(int& value) {
value += 42;
}

Now if the function was a little more advanced perhaps with several
parameters that shall be modified using a reference instead of a pointer
could make the code a lot clearer.

 

[Victor Bazarov]

[...]
But I take it you can put a reference as a data member of a class and in
creating an instance set the reference using a parameter.
This would satisfy assignment of a reference at runtime, wouldn't it?

No. It's not "assignment". It's "initialisation". Look it up.

Yes, of course, but what I am saying is: Can you set up a class with a
reference member, initialize it when the object is created and then use it.
By creating a new object of that class anytime you want to dynamically
"assign" that reference it satisfies the OP's question. Doesn't it?

I don't think so. Every time you instantiate such a class, you create
a _new_ reference, not _reuse_ the same one.

There is no need to play with words (and use double quotes) when it
comes to the language. Especially there is no need to substitute one
term with another when both are used with different meanings:
"an initialisation" is never "an assignment" and vice versa (you may
remove the double quotes and you will still have the true statement).

Victor