Assigning to references

[Dave]

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 within my control to change bar_t. Furthermore, I
need to be able to update the contained bar_t at runtime (hence the
set_bar() method seen below).

The code *almost* works. Here's the problematic line:

void set_bar(bar_t &b) {bar = b;}

This fails to compile with a message that operator= is inaccessible. Why
should this be a problem since I'm trying to assign to a reference? I only
want my reference member to refer to a new object; I'm not actually copying
an object. Why should operator= come into play? After all, I can pass a
reference to bar_t as a parameter just fine even though the copy constructor
is also inaccessible.

Assuming though that my compiler is behaving properly, I won't be able to
take this approach regardless of whether or not I understand why it's
disallowed. With that in mind, what's my next best alternative to create an
effect similar to what the code below attempts?

Thanks!
Dave

P.S. In case anyone is tempted to ask "What are you trying to do?", bar_t
corresponds to ofstream and foo_t corresponds to one of my application
classes. I need to contain an ofstream for logging, and I need to be able
to change that stream occassionally (i.e. start logging to a different
place).

class bar_t
{
public:
bar_t() {}

private:
bar_t(const bar_t &); // Leave undefined
bar_t &operator=(cons t bar_t &); // Leave undefined
};

class foo_t
{
public:
foo_t(): bar(initial_bar ) {}
void set_bar(bar_t &b) {bar = b;}

private:
bar_t initial_bar; // Must come *before* member bar as it is used to
initialize bar.
bar_t &bar;
};

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Julián Albo]

stelios xanthakis escribió:

Something like an unary pseudo-operator called "dereferenc e (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]

Ragnar wrote:

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

--
Best regards,
Andrey Tarasevich

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

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]

Andrey Tarasevich wrote:

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]

"Victor Bazarov" <v.********@com Acast.net> wrote in message
news:7B7sb.1252 67$ao4.386072@a ttbi_s51...

"Gary Labowitz" <gl*******@comc ast.net> wrote...

"Dave" <be***********@ yahoo.com> wrote in message
news:vr******** ****@news.super news.com...

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?

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?
--
Gary

[stelios xanthakis]

"Dave" <be***********@ yahoo.com> wrote in message news:<vr******* *****@news.supe rnews.com>...

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 "dereferenc e" 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]

On Wed, 12 Nov 2003 02:34:46 -0800, stelios xanthakis wrote:

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(i nt*);

int foo (int& x) {
store_pointer(& x);
}
Allowing to "dereferenc e" 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.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

[Victor Bazarov]

"Gary Labowitz" <gl*******@comc ast.net> wrote...

"Victor Bazarov" <v.********@com Acast.net> wrote in message
news:7B7sb.1252 67$ao4.386072@a ttbi_s51...

"Gary Labowitz" <gl*******@comc ast.net> wrote...

[...]
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