Reference to a reference

[deane_gavin]

yes, it runs fine.
there can't be error until you USE j. and I do not

My understanding, and I may be wrong, is that simply trying to
dereference i in your code is undefined behaviour. Even if you never
use j, from here on in anything (including the classic and unfortunate
"it did exactly what I expected") is possible.

Gavin Deane

 

[Andre Kostur]

Thanks for all your replies..Just to make clear that i've understood it
properly,
The following should be invalid program right ?

int main()
{
int i = 10;
int &r1 = i;
int &r2 = r1;

return 0;
}

Nope.

Right after the "int &r1 = i" line, anytime you use r1, it's really
referring to i (effectively). So when "int &r2 = r1" is done, it is
effectively the same as "int &r2 = i". Net result is that i, r1, and r2
all refer to i.

 

[makc.the.great]

To the OP: remember that
when one says that references may not be "NULL", there is an implicit "in a
well-formed C++ program" attached to the end of the statement. By
dereferencing a NULL pointer, the program is no longer well-formed.

how about replacing
int* i = 0;
with
int* i = some_obscure_function_returning_zero_on_rare_occasion();

 

[deane_gavin]

how about replacing
int* i = 0;
with
int* i = some_obscure_function_returning_zero_on_rare_occasion();

Then on those rare occasions, int&j = *i; invokes the same undefined
behaviour.

Gavin Deane

 

[makc.the.great]

Then on those rare occasions, int&j = *i; invokes the same undefined

behaviour.

yes, but the point was that my program is perfectly legal. this bad
function can, for example, be a part of somebody else's library.

 

[Senthil]

Nope.

Right after the "int &r1 = i" line, anytime you use r1, it's really
referring to i (effectively). So when "int &r2 = r1" is done, it is
effectively the same as "int &r2 = i". Net result is that i, r1, and r2
all refer to i.

Thanks for the enlightment folks

 

[deane_gavin]

yes, but the point was that my program is perfectly legal. this bad
function can, for example, be a part of somebody else's library.

While the usual request (particularly since Google went braindead) is
to snip more, it would actually help if you snipped a little less to
keep a bit more context.

The code in question is:

int* i = some_obscure_function_returning_zero_on_rare_occasion();
int&j = *i; // Undefined if i is null.

The name of that function suggests that it is expected to return zero
sometimes (rarely but still sometimes). In which case you need to check
for that before dreferencing i.

If what you actually meant was

int* i = library_function_that_should_not_return_zero_but_has_a_bug();
int&j = *i;

then you need to have a word with the library vendor.

Either way, if your code dereferences a null pointer, you have invoked
undefined behaviour. Well formed code does not do that.

Gavin Deane

 

[makc.the.great]

While the usual request (particularly since Google went braindead) is
to snip more, it would actually help if you snipped a little less to
keep a bit more context.

why? you do know what are we talking about.

The name of that function suggests that it is expected to return zero
sometimes (rarely but still sometimes).

the name of function doesn't suggest anything to a compiler. the
program is well-formed no matter how functions are named.

 

[deane_gavin]

why? you do know what are we talking about.

I've had to twice copy bits of context you'd deleted in order to make
my point. If I'm going to post a comment on some code or a response to
a question, I want my post to also contain that code or question.
Otherwise anyone reading it has to go back to previous messages in the
thread to understand what I'm on about. And I understand that forcing
people to have to do that is considered impolite.

the name of function doesn't suggest anything to a compiler. the
program is well-formed no matter how functions are named.

OK, we're into the precise definition of well-formed here aren't we.
And I'm not sure what that is. If I've got you right, you're argument
is that

int* i = third_party_library_function();
int& j = *i;

is well formed even if it may invoke undefined behaviour, because the
null pointer comes from outside _your_ code.

If that's what you're saying then I'll have to leave it to someone else
to explain whether the code is well formed. There _may_ be a
distinction between the case where third_party_library_function is
expected to return zero and the case where third_party_library_function
can never return zero (except it does because it has a bug).

Incidentally, I seem to be losing the space before j and after &. I've
no idea why.

Gavin Deane

 

[Rolf Magnus]

why? you do know what are we talking about.

This is not a private discussions. Others don't, and those shouldn't need to
dig into previous posts to search for what you are referring to. After all,
that's why quoting is done in usenet.

the name of function doesn't suggest anything to a compiler.

No, but to the user, it does. It suggests that the returned value might be a
null pointer, which means that he has to check for that condition before
dereferencing the pointer. If (and only if) you know that the function
_never_ returns a null pointer, you can omit that check.

the program is well-formed no matter how functions are named.

Syntactically, it's ok, but its behavior is undefined. If the returned
pointer is null, a null pointer is dereferenced, which invokes undefined
behaivor.

 

[Rolf Magnus]

oh wait. then
when?

we would loose math operations with pointers.

we would?

 

[Rolf Magnus]

OK, we're into the precise definition of well-formed here aren't we.
And I'm not sure what that is.

The C++ standard defines the term "well-formed program" as "a C++ program
constructed according to the syntax rules, diagnosable semantic rules, and
the One Definition Rule". Simplified, that means that it's well-formed if
the compiler can't detect any errors. However, that doesn't mean that the
code is correct.

If I've got you right, you're argument
is that

int* i = third_party_library_function();
int& j = *i;

is well formed even if it may invoke undefined behaviour, because the
null pointer comes from outside _your_ code.

It's well-formed, but still erroneous, because the "*i" invokes undefined
behavior for the case of i == 0, and invoking undefined behavior is an
error.

 

[Greg]

(e-mail address removed) wrote in @g43g2000cwa.googlegroups.com:


It may run too (without crashing). Doesn't matter. Undefined Behaviour
has been invoked by dereferencing a NULL pointer. To the OP: remember that
when one says that references may not be "NULL", there is an implicit "in a
well-formed C++ program" attached to the end of the statement. By
dereferencing a NULL pointer, the program is no longer well-formed. Try to
make a reference to "NULL" without invoking undefined behaviour first.

Actually dereferencing a NULL pointer does not by itself entail
undefined behavior, although the Standard is currently currently
somewhat inconsistent on that point. But according to Language Defect
report #232 the Standard needs to be more clear that that the undefined
behavior actually occurs by retrieving the value referenced by the null
pointer and not by deferencing the null pointer itself. In which case,
the program above is well-formed since j's value is not accessed.

Or, to take this an example from the defect report itself:

char *p = 0;
char *q = &*p;

Again these statements are well formed since the value referenced by p
is not obtained.

Greg

 

[makc.the.great]

This is not a private discussions. Others don't, and those shouldn't need to
dig into previous posts to search for what you are referring to. After all,
that's why quoting is done in usenet.

this is ridiculous. if, instead of quoting exactly words one is
referring to, s/he would quote all of above thread, lengthy discussions
would end up in multy-KBs messages noone would ever read. what's the
point? not to mention pointless servers overload.

and this "diggin in previous posts" part I don't understand. I usually
dig in next messages, because all discusions have their 1st messages -
if I were not interested in that message, why would I want to jump in
somwhere in the middle? on the other hand, if I did jumped in, it's
because middle message was that of interest, and digging back is not
necessary.

finally, if you don't like short messages, you don't have to replay at
all.

 

[Andre Kostur]

Actually dereferencing a NULL pointer does not by itself entail
undefined behavior, although the Standard is currently currently

Really? The standard seems to state it in a few places:

Section 1.9.4 Where it talks about undefined behaviour, uses
dereferencing a null pointer as an example

Section 8.3.2.4 (Which actually talks about "null" references) says that
"... obtained by dereferencing a null pointer which causes undefined
behaviour..."

somewhat inconsistent on that point. But according to Language Defect
report #232 the Standard needs to be more clear that that the
undefined behavior actually occurs by retrieving the value referenced
by the null pointer and not by deferencing the null pointer itself. In
which case, the program above is well-formed since j's value is not
accessed.

Or, to take this an example from the defect report itself:

char *p = 0;
char *q = &*p;

Again these statements are well formed since the value referenced by p
is not obtained.

I haven't read the defect report though... so I'll take your word on it.
But I'd expect that to be undefined behaviour as well...

 

[Andre Kostur]

(e-mail address removed) wrote in @g47g2000cwa.googlegroups.com:

OK, we're into the precise definition of well-formed here aren't we.
And I'm not sure what that is. If I've got you right, you're argument
is that

This will have to be my fault. I'm the one who brought the term "well-
formed" into the argument. I could have been more accurate. I should have
said "well-formed, and does not invoke undefined behaviour".

 

[deane_gavin]

this is ridiculous. if, instead of quoting exactly words one is
referring to, s/he would quote all of above thread, lengthy discussions
would end up in multy-KBs messages noone would ever read. what's the
point? not to mention pointless servers overload.

Who said anything about quoting the entire thread?

and this "diggin in previous posts" part I don't understand.

Which "diggin in previous posts" part? Part of what? What don't you
understand?

According to what you attribute to Rolf Magnus, he didn't mention
anything about digging in previous posts. Oh, I see. You didn't quote
enough context for your comment to be meaningful. QED

<snip>

Gavin Deane

 

[makc.the.great]

Part of what? What don't you
understand?
According to what you attribute to Rolf Magnus, he didn't mention
anything about digging in previous posts. Oh, I see. You didn't quote
enough context for your comment to be meaningful.

So?

Why should someone would comment on something, if he does not
understand what it is about? Just leave it ot, if you were not around
when it's started.

 

[deane_gavin]

So?

Why should someone would comment on something, if he does not
understand what it is about? Just leave it ot, if you were not around
when it's started.

You obviously missed the part about newsgroups not being the place for
private conversations (like this has become, so I'm stopping after this
post). But I guess you're happy that as long as _you_ understand your
own posts, you don't care that everyone else can't follow them. Fair
enough. At least we all know not to take any notice of anything you say
any more.

Gavin Deane

 

[Neo]

OK.. heres what i understood about references.

void swap(int &a, int &b)
{
int t=a,a=b,b=t;
}
int main()
{
int c=5,d=10;
swap(c,d);
/* here i thought that when compiling, c++ treats a nd b as c and d. So
i assumed i cannot use the function swap more than one time as a and b
cannot be substituted by another e and f.

if we indeed can then the compiler is internally looking into the
matter and substituting the pointers as required(we can see this in the
disassembly). this makes the reference arguement as a macro (which
saddens me)

What am i missing?
*/

}