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

Assigning to references

P: n/a
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=(const 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++.moderated. First time posters: Do this! ]
Jul 19 '05 #1
Share this Question
Share on Google+
37 Replies


P: n/a
> 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.
I think the error message put you on the wrong track. The compiler isn't
complaining about the assignment operator of the bar_t class. The real
problem is that C++ references in C++ are not assignable. They must
always be initialized and cannot be reseated later.
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?


If you need the bar member to reference another object at some point in
your program, the bar member must be a pointer.

[comp.lang.c++.moderated cross-post removed since it slows down
responses]

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl


Jul 19 '05 #2

P: n/a

Dave wrote:
Hello all, foo_t needs to contain a bar_t which is a class without a copy constructor
or operator=.

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.
You cannot do that in C++; a reference always refers to the object with
which it is initialized.
With that in mind, what's my next best alternative to create an
effect similar to what the code below attempts?


Pointers can be reassigned to refer to different objects.

HTH,
Jack
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #3

P: n/a

"Dave" <be***********@yahoo.com> wrote in message
news:vq************@news.supernews.com...
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?


not much analisys done but one thought:
references are *NOT* pointers. a reference is an alias (if you want) or a
different name for a variable. you initialise it and use it like any other
variable (use . not -> to call methods). The compiler may transform the
reference into a pointer, but this is only an implementation detail. So,
yes, you need an operator=

my 2c

/dan
<snip>

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #4

P: n/a
Dave wrote:
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).


NOW you're telling us :-)

std::ofstream log("foo", somemode);
.....
log.close();
log.open("bar", somemode);
.....

and in case you're afraid that someone uses your logging class in the mean
time, use two references, one unused, create the new stream and assign to
the unused reference, then assign the previously unused reference to the
previously used reference.
--

Ruurd
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #5

P: n/a
"Dave" <be***********@yahoo.com> wrote in message
news:vq************@news.supernews.com...
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? [snip]


Because you can't reassign a reference in C++. I have already given you the
answer to this problem twice now in a previous thread.

--
Cycho{HHR}
http://home.rochester.rr.com/cyhome/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #6

P: n/a
Hello Dave,

Dave schrieb:
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.
A reference in C++ is very near what we would name an "alias" of what it is
refering to. After initialization bar **is** the object of type T it was
initialized with,
thus an assignment to it calls the copy assignment operator of T.
References as function parameters behave as a transfer capsule from its actual
argument to the function internal accessor. The call

bar_t bobject;
....
set_bar(bobject);

creates a reference which binds to bobject. This reference is now available
inside
set_bar and no copy operation takes during function entry. This case is
different from

bar_t bobject;
....
bar_t& bref = bobject;

bref = bobject;

where the (non-initialization) assignment effectivly copies bobject into itself.

References as function parameters were quite useless, if they would call the
copy assignment operator of T, because this would make them not different
from "call-by-value".
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?


Use a pointer instead of a reference. Pointer do have two states (assigned and
not assigned) and thus can change between states (Reassignment is also allowed).

In many cases a reference is more appropriate than a pointer, because you don't
need to test, whether it is assigned or not: Once initialized it always is
assigned to the
same object!

In your case you want to allow a redirection of the target, you are "refering"
to,
so you need a pointer. This also makes you responsible for checking whether
the given pointer is a null pointer constant (not assigned) or not (assigned).

Hope that helps,

Daniel Spangenberg


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #7

P: n/a
"Dave" <be***********@yahoo.com> wrote in message news:<vq************@news.supernews.com>...
Hello all,

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


In C++, once a reference is seated, it can not be re-seated. You may
modify the referant, but you may not make it refer to a different
object.

"bar = b" calls operator= on 'bar', passing in 'b'.

It has to be this way. If 'bar=b' re-seated 'bar', how would you call
operator=?

If you want to have a reference and change what it refers to, use a
pointer:

pbar=&b;

*pbar << "hello" << endl;

joshua lehrer
factset research systems
NYSE:FDS

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #8

P: n/a
Hi,

Dave wrote:
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. class bar_t
{ private: bar_t &operator=(const bar_t &); // Leave undefined
That's why.
You cannot assgn to bar_t, because you have explicitly forbid it.
Note that:

- you cannot "reseat" the reference, and
- the reference always denotes some object

so the instruction:

bar = b;

tries to *assign* what is denoted by 'b' to what is denoted by 'bar'. In
other words, the above instruction tries to assign one bar_t object to
another, which is explicitly forbidden.

If you need to achieve the effect of reseating (without the possibility
to assign), consider using pointers instead of references.

I've used pointers recently in exactly the same context (logging ostream
object associated with another object).
class foo_t
{
public:
foo_t(): bar(initial_bar) {}
void set_bar(bar_t &b) {bar = b;}
bar = &b;
private:
bar_t &bar;
bar_t *bar;
};


--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #9

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


The problem is that references cannot be reassigned. Luckily enough, the
solution is simple: use a pointer.

Gerhard Menzl
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #10

P: n/a
On Thu, 06 Nov 2003 20:26:30 -0500, Dave wrote:
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;}
class foo_t {
public:
foo_t(bar_t *b);
void set_bar(bar_t *b) {bar = b;}
void set_bar(bar_t &b) {bar = &b;}
private:
bar_t *bar;
}

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.
You are calling the assignment operator, when you do "bar = b". The copy
constructor has nothing to do with it.
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 Logger {
public:
Logger();

void setStream(ostream &stream);

ostream& stream();
ostream& operator << (...);
private:
ostream *myStream;
}

....
Logger log(std::cout);

log.stream() << "blah\n";

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #11

P: n/a
"Dave" <be***********@yahoo.com> wrote in message news:<vq************@news.supernews.com>...
Hello all,

Hi Dave,

The answer is short and harsh I'm afraid. The Standard, (8.5.3-2),
states:

"A reference can not be changed to refer to another object
after initialization."

and this is exactly what you have hit upon. The compiler is happy
initialising
your reference in the ctor of foo_t, but after that it will not allow
bar to change. So, when you say

bar = b

the compiler resolves this to

deref(bar)->operator=( b );

which fails since operator= is private.

-=jarl

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #12

P: n/a

"Dave" <be***********@yahoo.com> wrote in message
news:vq************@news.supernews.com...
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
You Can't Change References. Once it has been constructed, a reference
behaves exactly like the object it refers to (it is an "alias" for that
object). Assigning to it is exactly the same as assigning to the original
object. Consider this code:

int a = 1;
int& b = a; // b refers to a
b = 2; // Now a == 2. "b" is simply an alias for "a".
int& c; // This is an error. You can't have a reference that doesn't
refer to anything.
int& d = b; // d refers to b, which is the same as a
b = d; // Exactly equivalent to "a = a".

Contrast this with the behaviour of pointers:

int a = 1;
int* b = &a; // b points to a
*b = 2; // Now a == 2.
int c = 3;
int* d = &c; // d points to c
b = d; // b points to whatever d points to (i.e. c)
c = 4;
assert(*b == 4);
// Note the contrast of *b, meaning the object b points to, and b, the
pointer itself.
// References make no such distinction; you are always referring to the
referenced object.

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?

What you probably meant to do is have the member bar be a *pointer*.

For example:

class foo_t
{
bar_t* bar;
public:
foo_t(): bar(0) { }
void set_bar(bar_t& b) { bar = &b; }
void do_something() { bar->do_something(); }
};

Bear in mind that, unlike a reference, a pointer will not extend the
lifetime of the object it points to. So if you were to write code like
this:

void give_me_a_bar(foo_t& foo)
{
bar_t bar;
foo.set_bar(bar);
}

int main()
{
foo_t foo;
give_me_a_bar(foo);
foo.do_something(); // crash here
}

then the Result Is Undefined.

Regards
David Turner

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #13

P: n/a
Dave wrote:
<snip>
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?

<snip>

You misunderstand what a reference is. Assigning to a reference
means assigning to the object it refers to, not binding the
reference to another object.

You need to store a pointer instead, and use unary * and &
operators to convert between pointers and references.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #14

P: n/a
In article <vq************@news.supernews.com>, Dave
<be***********@yahoo.com> writes
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.


You have misunderstood what a reference is in C++. It is purely a name
that is bound to an existing object and the language does not provide a
normal mechanism for rebinding the name to a different object.
operator=() deals with objects and values not with names so bar = b
requires that the value of b be assigned to the object referred to by
bar. As there is no operator=() for the type in question this cannot be
done.

The special property of reference parameters is that binding between
name and object takes place as part of the process of calling the
function so that parameter name can be bound to many different objects,
but each time that binding is for the duration of the function call.

The best you can do is to explicitly change any publicly writable
characteristics of the object:

void change_bar(bar_t& b){
bar.write_val1(b.read_val1());
bar.write_val2(b.read_val2());
etc.
}

But be very careful if your process is multi-threaded because it seems
that bar is a global variable and so the above process must be protected
by something such as a mutex.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #15

P: n/a
"Dave" <be***********@yahoo.com> wrote in message news:<vq************@news.supernews.com>...
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.


You cannot reset a reference. The instruction above tries to assign
directly to bar. The solution is to define bar as a pointer to a bar_t
and change set_bar() to

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

Cheers,
Nicola Musatti

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #16

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave wrote:

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

You never assign *to* references, you assign *through* references.

A reference is a different name for an object, and must be bound
when created, and can never be rebound.

References are second class citizens in the C++ world.

You cannot have references to references, you cannot have pointers
to references, if you take the address of a reference (operator&)
you get the address of the referent that the reference is bound
to, etc...

If you're familiar with Pascal, a reference is like adding the
keyword "var" in front of a parameter in a parameter list.

procedure foo(a: integer); begin ... end;
procedure bar(var a: integer); begin ... end;

In C++, we would say:

void foo(int a) { ... }
void bar(int &a) { ... }

In either case, the name "a" in procedure "bar" is, for
all practical purposes, an int-typed variable; it just happens
to be stored differently from the "a" in "foo".

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/q7WOJJVk0d/xqeYRAonUAJ9alYAEtsPy03NSZu+ne59JT2efBACgiPUN
VhJt7JCc1kTXFEKhU6CNTks=
=ZDoM
-----END PGP SIGNATURE-----

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #17

P: n/a
On Thu, 06 Nov 2003 20:26:30 -0500, Dave wrote:
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;}


C++ references are just aliases to existing objects; they cannot be
reseated. Try using a pointer instead, since that has the meaning you are
after here.

HTH,

Simon Bone
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #18

P: n/a
Ron
> 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.

class bar_t
{
public:
bar_t() {}

private:
bar_t(const bar_t &); // Leave undefined
bar_t &operator=(const 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;
};


The compiler accepts the line

foo_t(): bar(initial_bar) {}

-- even though bar_t has no accessible copy constructor -- because
this line binds the reference "bar" to the member variable
"initial_bar". The line

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

fails to compile because it's asking the compiler to copy the object
"b" into the object to which the reference "bar" is bound.

Huh? That's right: references can be bound only once. After they're
bound, they refer to the same object forever*. Section 8.5.3(2):

A reference cannot be changed to refer to another object after
initialization. Note that initialization of a reference
is treated very differently from assignment to it....

Thus:

int i;
int &r = i; // r is now an alias for i
r = 3; // i now == 3. r DOES NOT refer to the rvalue "3".
r = 6; // i now == 6

-Ron

* Putting aside nasssty treacherous rebinding tricks using explicit
destructor calls and placement new.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 19 '05 #19

P: n/a

"Dave" <be***********@yahoo.com> wrote in message
news:vq************@news.supernews.com...
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=(const 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;
};


Hello all,

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...). So, I'm having some trouble here. In any
case, I just wanted to thank everyone for all of the responses. I can't
believe I had such a massive mental lapse! Your points are very well made
and very well taken!

As long as I'm writing, I'll make one more query. This is purely out of
curiosity - I'm not trying to do anything specific. And of course, if there
*is* a way to do what I'm about to ask about, it would no doubt be very
ill-advised so, again, this is purely out of curiosity...

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

Thanks again,
Dave
Jul 19 '05 #20

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

--
Best regards,
Andrey Tarasevich

Jul 19 '05 #21

P: n/a
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
Jul 19 '05 #22

P: n/a

"Ron" <rc****@ictv.com> wrote in message news:c6**************************@posting.google.c om...
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.
Jul 19 '05 #23

P: n/a
Dave wrote:
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?

Andrey Tarasevich <an**************@hotmail.com> wrote 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.
Jul 19 '05 #24

P: n/a
Andrey Tarasevich <an**************@hotmail.com> wrote in message news:<vq************@news.supernews.com>...
Dave wrote:
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.


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.
Jul 19 '05 #25

P: n/a
"Dave" <be***********@yahoo.com> wrote :
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.

--
Ragnar
Jul 19 '05 #26

P: n/a
> 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!!!
Jul 19 '05 #27

P: n/a

"Ragnar" <at*******@yahoo.com> wrote in message
news:9c**************************@posting.google.c om...
"Dave" <be***********@yahoo.com> wrote :
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.

--
Ragnar


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

P: n/a
"Dave" <be***********@yahoo.com> wrote in message
news:vr************@news.supernews.com...
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!!!


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?
--
Gary
Jul 19 '05 #29

P: n/a
"Gary Labowitz" <gl*******@comcast.net> wrote...
"Dave" <be***********@yahoo.com> wrote in message
news:vr************@news.supernews.com...
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!!!


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
Jul 19 '05 #30

P: n/a
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.
Jul 19 '05 #31

P: n/a
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

Jul 19 '05 #32

P: n/a
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
Jul 19 '05 #33

P: n/a
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

Jul 19 '05 #34

P: n/a
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:7B7sb.125267$ao4.386072@attbi_s51...
"Gary Labowitz" <gl*******@comcast.net> wrote...
"Dave" <be***********@yahoo.com> wrote in message
news:vr************@news.supernews.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
Jul 19 '05 #35

P: n/a
"Dave" <be***********@yahoo.com> wrote in message news:<vr************@news.supernews.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 "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
Jul 19 '05 #36

P: n/a
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(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.

--
NPV

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

Jul 19 '05 #37

P: n/a
"Gary Labowitz" <gl*******@comcast.net> wrote...
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:7B7sb.125267$ao4.386072@attbi_s51...
"Gary Labowitz" <gl*******@comcast.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

Jul 19 '05 #38

This discussion thread is closed

Replies have been disabled for this discussion.