Null reference

[Phlip]

It is, quite frankly, the only valid way. Just look at the hackery
required to check a "null" reference. You can't say assert( ref ).
You have to say assert( &ref ). This is just plain nonsensical. Can
they guarantee that will always work the way the expect and doesn't
cause undefined behavior of its own?

Once a program enters the undefined behavior, its state is never defined
again. So the undefinity of assert(&ref) itself is a moot point.

 

[Noah Roberts]

I imagine they will want to do something like:
void f( const int &n )
{
assert(&n);
// ...
}

Yes, get out of there. If they want to assert a reference then they
are not asserting their pointers. Your team has lost it dude. Some
sort of screwy group-think going on triggered by an "expert" who
obviously doesn't understand a damn thing.

 

[Noah Roberts]

Once a program enters the undefined behavior, its state is never defined
again. So the undefinity of assert(&ref) itself is a moot point.

I know but it's just more ammo against having to do something totally
stupid. Actually assert( &ref ) is not undefined...it is the undefined
nature of the program that causes that statement to be unpredictable.

I'll use undefined behavior if I have to and am targeting a very
specific architecture but I certainly don't rely on it unless I have to
and I certainly don't when there is a better, more correct way of doing
what I want. Check a pointer's validity while it is a pointer is one
of those cases.

Any time you use undefined behavior in your program you run the risk
that something could hapen that causes it to break down....and just
because a reference is always going to be a pointer doesn't mean that
the undefinedness goes away or that the architecture itself couldn't
change in a way that makes the program unpredictable. Use it VERY
judiciously.

The point I was trying to make really is that there is no way to check
the validity of a reference. There is also no need since the reference
is known to be valid since pointers are always checked...in code not
made by retarded monkeys.

 

[Noah Roberts]

They expect that references will be implemented as pointers in all future versions, and
that assigning a reference to a dereferenced pointer will not actually perform the
dereference, and they are almost certainly right. That's the problem, really. There's no
other reasonable implementation and they know it.

Actually, they are likely wrong in many cases. I would expect a
reference assignment could look something akin to:

int * ref = &(*p);

That is a very reasonable implementation at the least even if it isn't
very optimized.

At any rate, guessing what the implementation is doing here and
depending on it is just plain stupid. There is no other way to say it.
There are at least two assumptions going on: 1) references and
pointers are the same; and 2) assigning a dereferenced pointer to a
reference is just a copy and doesn't dereference the pointer. Neither
of these are known facts and the implementation is free to do
otherwise. The fact that there is _absolutely_ no reason to do this,
ever, only compounds the fact that it shouldn't be done.

 

[Guest]

* Harald van Dijk:

No, s is not of aggregate type. But that's just a nit... ;-) Put in a
default constructor and leave out the initializer.

Is the standard's wording different from the draft? That says
"An aggregate is an array or a class (clause 9) with no user-declared
constructors (12.1), no private or protected non-static data members
(clause 11), no base classes (clause 10), and no virtual functions
(10.3)."

Anyway, if that's not allowed, thanks for the info. It didn't seem
directly relevant to the question, so I simply relied on my compilers.
Two of them don't complain about it regardless of options, and a third
gives a highly misleading error message ("A non-const reference can't
be initialized using an rvalue"). But pretend I used a constructor,
then.

Undefined behavior is undefined even if a compiler defines it.

Right, but that's not what I meant. I didn't mean it would "work", I
asked at what point the behaviour would be undefined. Any object can be
read from and written to as an array of (unsigned) char, right? Sure,
reading the object afterwards is not allowed if a non-value is written,
but I specifically said s.r would never be used. (If it makes a
difference, s would never be used.)

Naturally, because otherwise there would be /no/ undefined behavior: any
construct that has formally undefined behavior results in some concrete
behavior on a concrete system, and that concrete behavior is a
definition of the behavior on that system.

Yeah, anyone can define anything, and definitions aren't authoritative
unless the C++ standard says they are. No problem, that I get.

 

[Alf P. Steinbach]

* Harald van Dijk:

Is the standard's wording different from the draft? That says
"An aggregate is an array or a class (clause 9) with no user-declared
constructors (12.1), no private or protected non-static data members
(clause 11), no base classes (clause 10), and no virtual functions
(10.3)."

Anyway, if that's not allowed, thanks for the info. It didn't seem
directly relevant to the question, so I simply relied on my compilers.
Two of them don't complain about it regardless of options, and a third
gives a highly misleading error message ("A non-const reference can't
be initialized using an rvalue"). But pretend I used a constructor,
then.

Thanks, I was wrong, it actually is an aggregate (the definition of POD
explicitly excludes aggregates with references). So instead of a
constructor you can just put an int variable in the initializer. Learned
something today...

Right, but that's not what I meant. I didn't mean it would "work", I
asked at what point the behaviour would be undefined.

Not sure whether this code (when the initialization is corrected) /has/
undefined behavior.

Any object can be
read from and written to as an array of (unsigned) char, right?

Depends what you mean. In practice, yes, with the limitation that the
address range of a non-POD object obtained from & and sizeof may not
always contain the complete representation of the object. In the
formal, no (you can do that for POD type per §3.9/1 but the standard
doesn't guarantee the result for non-POD type), and furthermore, in the
formal, a reference isn't an object.

 

[David W]

Yes, get out of there. If they want to assert a reference then they
are not asserting their pointers. Your team has lost it dude. Some
sort of screwy group-think going on triggered by an "expert" who
obviously doesn't understand a damn thing.

It's not quite that bad yet. We are still in a discussion phase about it, but it hasn't
been discussed in the last day. I'm hoping it will just fade away now.

David

 

[Phlip]

It's not quite that bad yet. We are still in a discussion phase about it,
but it hasn't been discussed in the last day. I'm hoping it will just fade
away now.

Remember the ancient words of wisdom "softlee softlee catchee monkey".
That means if the monkey(s) sees you coming thinking about catching them,
they will run away. If you just walk past, obviously and honestly with
nothing on your mind, they won't notice you until it's too late. Don't
spook them.